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:

quoted

quoted

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