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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Tue, 8 May 2012 12:48:44 +0200
From:	Michal Hocko <mhocko@...e.cz>
To:	Tejun Heo <tj@...nel.org>
Cc:	Hiroyuki Kamezawa <kamezawa.hiroyuki@...il.com>,
	David Rientjes <rientjes@...gle.com>,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Randy Dunlap <rdunlap@...otime.net>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Richard Weinberger <richard@....at>,
	KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
	Johannes Weiner <hannes@...xchg.org>
Subject: Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/