lkml.org 
[lkml]   [2012]   [Mar]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFD] cgroup: about multiple hierarchies
    Quoting Tejun Heo (tj@kernel.org):
    > Hello, guys.
    >
    > Thanks a lot for the discussion and here are my take aways:
    >
    > * At least to me, nobody seems to have strong enough justification for
    > orthogonal multiple hierarchies, so, yeah, unless something else

    First off, can you (sorry) show an example of exactly what would no
    longer be supported? Is this the ability to not separately mount
    freezer and cpusets (for instance)?

    I've submitted a topic for the upcoming linux foundation end user summit
    in new york, to get feedback from end users. (Frankly I don't want to go
    so would love if someone else wanted to do this :). I think it'd be nice
    to wait and see if this gets accepted, and see whether any end users are
    relying on this.

    (IMO it's wrong to say that "if you are using a current feature, you'd
    better be reading lkml so you can speak up lest that feature might get
    removed.")

    > happens, I'm scheduling multiple hierarchy support for the chopping
    > block. This is a long term thing (think years), so no need to panic
    > right now and as is life plans may change and fail to materialize,
    > but I intend to at least move away from it.
    >
    > * Several people pointed out that it would be inconvenient to require
    > cgroup hierarchy to be a strict super-imposed tree on top of process
    > tree and that program groups / sessions aren't like that either. I
    > agree, so it will hopefully be single hierarchy which more or less
    > behaves the same as the current hierarchy.
    >
    > * How to map controllers which aren't aware of full hierarchy is still
    > an open question but I'm still standing by one active node on any
    > root-to-leaf path w/ root group serving as the special rest group.
    >
    > This should happen first for the long migration to begin. I might
    > get to it someday but if anyone can beat me to it, please go ahead.
    > I'll be ecstatic to review and merge the patches.
    >
    > Also, I'll slowly be marking features which don't seem essential,
    > especially the convenience features for multiple hierarchies, as
    > deprecated and eventually chop them.
    >
    > Thank you.
    >
    > --
    > tejun
    > _______________________________________________
    > Containers mailing list
    > Containers@lists.linux-foundation.org
    > https://lists.linuxfoundation.org/mailman/listinfo/containers


    \
     
     \ /
      Last update: 2012-03-12 23:39    [W:0.023 / U:1.832 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site