Re: [PATCH v2 14/14] Change CPUACCT to default n
From: Glauber Costa
Date: Thu Nov 17 2011 - 10:59:30 EST
On 11/17/2011 12:58 AM, Balbir Singh wrote:
On Thu, Nov 17, 2011 at 8:19 AM, Glauber Costa<glommer@xxxxxxxxxxxxx> wrote:
On 11/16/2011 09:52 PM, KAMEZAWA Hiroyuki wrote:
On Wed, 16 Nov 2011 15:51:27 +0530
Balbir Singh<bsingharora@xxxxxxxxx> wrote:
On the other hand, I don't think much discussion remains for cpuacct,
everyone's pretty unanimous in that they'd like to see it deprecated.
By splitting this up we can close out that quickly while we figure out
the
best way to resolve the above.
I'd give it a thumbs up, if we can create sched groups and provide
accounting without control - like we can for the memory cgroup today.
Isn't it possible ?
Thanks,
-Kame
I must say I don't really understand what exactly you propose, and how it is
different from what we have today.
My take is that you are talking about a single cgroup in which you can have
the functionality of both cpuacct and cpu, but surrounded by knobs that
allows you to turn them off individually.
Am I right?
No here is what I am asking for
I don't want CPU control, just accounting, so I create the following groups
a
/ \
V V
b c
Today, with the cpu controller, the moment I create a, b and c, they
get default shares and if I put tasks, their b/w is decided by the
shares, what if I don't want control, but I want to account for their
time only?
Balbir
I think that if this really a requirement, cpuacct should stay. I was
working under the assumption that it was not really an important case -
so thanks for the clarification. Peter and Paul can chime in here, but I
think that this requirement poses constraints to the cpu cgroup and
consequently the scheduler - both in its current incarnation and in what
come in the future - that may not be acceptable. What I am concerned
about is that it might mandate the scheduler to always test whether or
not the grouping has a scheduling effect or not - and then walk the
group if it is not, etc. In a summary, if we can or cannot bundle
processes together for scheduling purposes, we'll likely need separate
data structures anyway.
A lot of the code I wrote can be reused to at least make it faster in
the case in which only the root is mounted - for cpuacct.stat at least.
However, the big question remains: The most expensive operation for
cpuacct also seem to be the most important, cpuusage, which was a big
part of the motivation to bundle them all together. Maybe then Paul's
co-mounting idea starts to make sense, but it will still be quite slow
for your usage, in which the groups are clearly different.
I think the best I can come up with right now, is to base my work on
cpuacct - I am fine with that, and it was actually how my first version
looked like - and then think about a way to make cpuusage faster later...
--
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/