[lkml]   [2012]   [May]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

    (cc'ing Johannes and Michal, hi guys)

    On Fri, May 04, 2012 at 08:17:11AM +0900, Hiroyuki Kamezawa wrote:
    > > Cgroups is moving to a single hierarchy for simplification, this isn't the
    > > only example of where this is currently suboptimal and it would be
    > > disappointing to solidify hugetlb control as part of memcg because of this
    > > current limitation that will be addressed by generic cgroups development.
    > >
    > > Folks, once these things are merged they become an API that can't easily
    > > be shifted around and seperated out later.  The decision now is either to
    > > join hugetlb control with memcg forever when they act in very different
    > > ways or to seperate them so they can be used and configured individually.
    > How do other guys think ? Tejun ?

    I don't know. hugetlbfs already is this franken thing which is
    separate from the usual memory management. It needing cgroup type
    resource limitation feels a bit weird to me. Isn't this supposed to
    be used in more-or-less tightly controlled setups? The whole thing
    needs to have its memory cut out from boot after all.

    If someone really has to add cgroup support to hugetlbfs, I'm more
    inclined to say let them play in their own corner unless incorporating
    it into memcg makes it inherently better.

    That said, I really don't know that much about mm. Johannes, Michal,
    what do you guys think?


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2012-05-04 20:01    [W:0.027 / U:8.152 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site