Messages in this thread | | | Date | Wed, 11 Mar 2009 21:04:34 +0530 | From | Balbir Singh <> | Subject | Re: [RFC PATCH] cpuacct: per-cgroup utime/stime statistics - v1 |
| |
* KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2009-03-11 09:38:12]:
> On Tue, 10 Mar 2009 18:12:08 +0530 > Bharata B Rao <bharata@linux.vnet.ibm.com> wrote: > > > Hi, > > > > Based on the comments received during my last post > > (http://lkml.org/lkml/2009/2/25/129), here is a fresh attempt > > to get per-cgroup utime/stime statistics as part of cpuacct controller. > > > > This patch adds a new file cpuacct.stat which displays two stats: > > utime and stime. I wasn't too sure about the usefulness of providing > > per-cgroup guest and steal times and hence not including them here. > > > > Note that I am using percpu_counter for collecting these two stats. > > Since percpu_counter subsystem doesn't protect the readside, readers could > > theoritically obtain incorrect values for these stats on 32bit systems. > > Using percpu_counter_read() means that .. but is it okay to ignore "batch" > number ? (see FBC_BATCH) >
FBC_BATCH? Thats gone..no? We have dynamic batches now, IIRC. Could you please elaborate on your comment?
> > > I hope occasional wrong values is not too much of a concern for > > statistics like this. If it is a problem, we have to either fix > > percpu_counter or do it all by ourselves as Kamezawa attempted > > for cpuacct.usage (http://lkml.org/lkml/2009/3/4/14) > > > Hmm, percpu_counter_sum() is bad ? >
Yes, but we need to sum somewhere.. user space summing will not be atomic, we'll get several snapshots of per CPU data and summing it might not yield the correct answers.
> BTW, I'm not sure but don't we need special handling if > CONFIG_VIRT_CPU_ACCOUNTING=y ?
Good point. Bharata, with CONFIG_VIRT_CPU_ACCOUNTING, utime and stime is accounted for within the architecture.
-- Balbir
| |