[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <47F85BB1.8010503@linux.vnet.ibm.com>
Date: Sun, 06 Apr 2008 10:42:17 +0530
From: Balbir Singh <balbir@...ux.vnet.ibm.com>
To: Balaji Rao <balajirrao@...il.com>
CC: Dhaval Giani <dhaval@...ux.vnet.ibm.com>,
linux-kernel@...r.kernel.org, containers@...ts.osdl.org,
menage@...gle.com, a.p.zijlstra@...llo.nl, balbir@...ibm.com,
Srivatsa Vaddagiri <vatsa@...ux.vnet.ibm.com>
Subject: Re: [RFC][-mm] [1/2] Simple stats for cpu resource controller
Balaji Rao wrote:
> On Sunday 06 April 2008 02:29:14 am Dhaval Giani wrote:
>> On Sun, Apr 06, 2008 at 02:01:52AM +0530, Balaji Rao wrote:
>>> On Sunday 06 April 2008 01:10:41 am Dhaval Giani wrote:
>>>>> +};
>>>>> +
>>>>> +struct cpu_cgroup_stat_cpu {
>>>>> + s64 count[CPU_CGROUP_STAT_NSTATS];
>>>> u64? time does not go negative :)
>>> Right. But these stats are not only going to measure time. We need the
> same
>>> variables for measuring other stats as well. I'm not sure if we would
>>> encounter scheduler stats that would count negative.
>>>
>>> Balbir, what do you say ?
>> I would prefer to keep the stats logically separate. So something like
>> struct cpu_cgroup_stat_cpu {
>> u64 time[];
>> s64 some_other_stat;
>> }
>> and so on. (I am not sure, is there some advantage gained by using
>> structs?) Makes the code more maintainable imho.
>>
> This would break the generic nature of __cpu_cgroup_stat_add. Its not a nice
> thing in my opinion.
>
I prefer keeping stats in the array as Balaji has done, it makes it easier to do
batch processing on the stats.
--
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists