On Fri 04-05-12 10:24:20, Tejun Heo wrote: > 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. I would agree with you but my impression from the previous (hugetlb) implementation was that it is much harder to implement the charge moving if we do not use page_cgroup. Also the range tracking is rather ugly and clumsy. > That said, I really don't know that much about mm. Johannes, Michal, > what do you guys think? > > Thanks. > > -- > tejun -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic -- 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
