Hello, (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? Thanks. -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
