[lkml]   [2011]   [Nov]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH v2 14/14] Change CPUACCT to default n
    On 11/17/2011 12:58 AM, Balbir Singh wrote:
    > On Thu, Nov 17, 2011 at 8:19 AM, Glauber Costa<> wrote:
    >> On 11/16/2011 09:52 PM, KAMEZAWA Hiroyuki wrote:
    >>> On Wed, 16 Nov 2011 15:51:27 +0530
    >>> Balbir Singh<> 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...

     \ /
      Last update: 2011-11-17 17:01    [W:0.024 / U:1.036 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site