Re: [PATCH 1/9] Remove parent field in cpuacct cgroup

[Peter Zijlstra <a.p.zijlstra@chello.nl>]

On Mon, 2011-09-19 at 13:09 -0300, Glauber Costa wrote:
> On 09/19/2011 01:03 PM, Peter Zijlstra wrote:
> > On Wed, 2011-09-14 at 17:04 -0300, Glauber Costa wrote:
> >> +       for (; ca; ca = parent_ca(ca)) {
> >
> > It might be good to check that the loop condition and null condition in
> > the parent_ca() function get folded. Otherwise there's a double branch
> > in that loop.
> >
> > Note that this function is one of the reasons I dislike cpuacct, it adds
> > a second cgroup hierarchy traversal to every context switch.
> >
> Well, it is not that hard to optimize this.
> 
> Those values are always updated, but they don't really need to, unless 
> they are read.
> 
> So what we can do, is introduce a marker in the cgroup, representing the 
> last read value. Parent is untouched. We then update parent when 1) 
> reading this value, 2) cgroup destroy, 3) cpu hotplug. (humm, and maybe 
> we don't even need to do it in cpu hotplug, since the per-cpu variables 
> will still be accessible... )
> 
> How about it ?

Updating that value would involve iterating all tasks in the entire
cgroup subtree nested at whatever cgroup you're wanting to read.

The delayed update would be an entire subtree walk, that can be quite
expensive. Who wants these numbers and what for and at what frequency?
Does that really make sense?