Thread (29 messages) 29 messages, 10 authors, 2012-05-08

Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

From: Tejun Heo <tj@kernel.org>
Date: 2012-05-04 17:24:27
Also in: lkml

Hello,

(cc'ing Johannes and Michal, hi guys)

On Fri, May 04, 2012 at 08:17:11AM +0900, Hiroyuki Kamezawa wrote:
quoted
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?

Thanks.

-- 
tejun
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help