On Mon 07-05-12 10:08:40, Tejun Heo wrote: > Hello, > > On Mon, May 07, 2012 at 04:01:04PM +0200, Michal Hocko wrote: > > > 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. > > Understood. I haven't looked at the code, so my opinion was based on > the assumption that the whole thing is completely separate (in design > and implementation) from memcg as hugtlbfs is from the usual mm. If > it's better / easier implemented together with memcg, I have no > objection to making it part of memcg. I think we could still consider a possibility of using page_cgroup for tracking without the rest of memcg infrastructure (charging) in place. It sounds like the memory overhead would be too big (at least now) for relatively few hugetlb pages in use but it would reduce the performance hit if a user is interested only in the hugetlb limits (mentioned by David in the other email). On the other hand we are on the way to get rid of page_cgroup and push the missing parts into the struct page. Then we could accomplish the hugetlb only use case by cgroup_disable=memory hugetlbaccount=1 kernel parameters (yes still not very nice...). That being said I think that going memcg way is simpler and that the !memcg && hugetlb use case is still possible (somehow). Or does anybody have a different idea? -- 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
