lkml.org 
[lkml]   [2011]   [Nov]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v2 14/14] Change CPUACCT to default n
On Fri, Nov 25, 2011 at 2:19 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> On Fri, 2011-11-25 at 11:08 +0530, Balbir Singh wrote:
>> It is not about $customer. I am OK with a design that allows
>> accounting independent of control. Put it another way when I look at
>> cgroups, I see the following functionality
>>
>> 1. Accounting and feedback
>> 2. Control
>>
>> Why do 1 and 2 have to co-exist. A good case would be that we might
>> need just stats and might want to implement control based on 1.
>
> I would say that 2 always requires 1 (provided they are of course on the
> same subject), for the very simple reason that you need to know the
> current state (as provided by 1) to control it (2).
>
> Therefore separating them leads to useless duplication.

Almost all of the stats that are coming in here are completely useless
for control and don't belong in the cpu controller.

While it's not as pure we really have 2 tiers of statistic:

1) Accounting needed for control
2) Everything else

What causes so much over-head for cpuacct currently is that it tries
to maintain a separate accounting of usage. If this were removed from
the controller then it would be *much* cheaper, even with all extra
stats added here.

This series adds a lot of statistics in the second category, they
really have no common touch points on the cpu controller path. That
second category could be re-worded as 'accounting how scheduled time
is spent' as opposed to the actual accounting of scheduling decisions.
I would really rather not see anything in that category weighing down
the cpu-controller any more than it already is.

- Paul
>
>> But if
>> I have to do both 1 and 2 together, how do we decide on control
>> values?
>
> Uh, what?
>
> What was not answered is, is there a sane reason to have both on
> different hierarchies? I think the whole different hierarchy per
> controller thing is one of the biggest trainwrecks of cgroups.
>
> It allows for great confusion, but I haven't yet seen an up-side to it.
>


\
 
 \ /
  Last update: 2011-11-26 14:21    [W:0.058 / U:2.200 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site