Re: [PATCH 1/9] Remove parent field in cpuacct cgroup
From: Glauber Costa
Date: Mon Sep 19 2011 - 15:15:42 EST
On 09/19/2011 03:44 PM, Peter Zijlstra wrote:
On Mon, 2011-09-19 at 15:38 -0300, Glauber Costa wrote:
On 09/19/2011 03:35 PM, Peter Zijlstra wrote:
On Mon, 2011-09-19 at 13:30 -0300, Glauber Costa wrote:
For cpuusage, I am not sure this optimization is a valid one
I was talking about cpuusage, cpuacct_charge() is called for every
ctxsw/tick.
I am not touching it right now.
See hunk #4 of this particular patch:
@@ -9302,7 +9308,7 @@ static void cpuacct_charge(struct task_struct *tsk, u64 cputime)
That's cpuusage muck ;-)
Well, sure. But then, the only thing I am doing in this particular hunk
is changing the definition of how to grab a parent... Can easily even be
left aside.
But even for cpuacct tick stuff, wouldn't you need to sum all your child
cgroups to update the current cgroup? and that up the whole tree?
Of course I would. But as I said, it does not need to be done every
tick, in case it poses such a cacheline mayhem as you fear.
Since we'll only really need those values when someone reads it - which
is a far less frequent operation than the tick resolution - and when a
cgroup is destroyed - even less frequent operation - it should work well.
Quite possible, yes. Although if you create a cgroup with 100 subgroups
and poll very frequently.. it all depends on the avg use case etc.. and
since I don't use any of this stuff someone needs to tell me about how
the trade-offs work out in practice.
So explicit changelogs with numbers and agreements from multiple users
go a long way to make me feel good ;-)
Well, thinking again about that, maybe it is not that much of a good
idea. systemd is already starting to span a lot of cgroups... and if we
update the tree bottom-up, we actually do have a much larger cost, since
we need to touch all its breath...
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/