lkml.org 
[lkml]   [2011]   [Sep]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [RFD 0/9] per-cgroup /proc/stat statistics
    From
    Date
    On Fri, 2011-09-23 at 19:20 -0300, Glauber Costa wrote:
    > Hi,
    >
    > Since I've sent already a RFC about it, I am sending now a RFD.
    > If you eager for meaning, this can then be a "Request for Doctors",
    > since Peter is likely to have a heart attack now.

    :-)

    All we need is to ensure the case of cgroups enabled but not used isn't
    actually more expensive that what we have now, after that, if people
    create a 100 deep cgroup hierarchy they get what they asked.

    From a conceptual pov this patch-set is a lot saner than the previous
    one, doesn't duplicate nearly as much and actually tries to improve the
    code (although I suspect simply killing off cputime64_t as a whole will
    get us even more).

    > So here's the deal:
    >
    > * My main goal here was to demonstrate that we can avoid double accounting
    > in a lot of places. So what I did was getting rid of the original and first
    > kstat mechanism, and use only cgroups accounting for that. Since the parent
    > is always updated, the original stats are the one for the root cgroup.

    Right, current patch-set won't compile for those who have CGROUP=n
    kernels though, need to find something for that. Shouldn't be too hard
    though. It looks like you only need to provide static per-cpu storage
    and a custom version of task_cgroup_account_field().

    > * I believe that all those cpu cgroups are confusing and should be unified. Not
    > that we can simply get rid of it, but my goal here is to provide all the
    > information they do, in cpu cgroup. If the set of tasks needed for accounting
    > is not independent of the ones in cpu cgroup, we can avoid double accounting
    > for that. I default cpuacct to n, but leave it to people that wants to use it
    > alone.

    Amen! Ideally we place cpuacct on the deprecated list or somesuch..

    > * Well, I'm also doing what I was doing originally: Providing a per-cgroup version
    > of the /proc/stat file.

    Right, so how much sense does it make to keep calling it proc.stat?


    \
     
     \ /
      Last update: 2011-09-28 00:15    [W:0.022 / U:62.592 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site