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:Well, it is not that hard to optimize this.+ 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.
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 quiteBut the subtrees are small, because we are talking about the cgroup subtree, wich can grow quite a lot in breadth, but rarely in depth.
expensive.
Who wants these numbers and what for and at what frequency?
Does that really make sense?