[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
    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.034 / U:59.628 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site