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] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.00.1205030208120.21476@chino.kir.corp.google.com>
Date:	Thu, 3 May 2012 02:13:52 -0700 (PDT)
From:	David Rientjes <rientjes@...gle.com>
To:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
cc:	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>
Subject: Re: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)

On Sat, 28 Apr 2012, Aneesh Kumar K.V wrote:

> My first version was to do it as a seperate controller 
> 
> http://thread.gmane.org/gmane.linux.kernel.mm/73826
> 
> But the feedback I received was to do it as a part of memcg extension,
> because what the controller is limiting is memory albeit a different
> type. AFAIU there is also this goal of avoiding controller proliferation.
> 

Maybe Kame can speak up if he feels strongly about this, but I really 
think it should be its own controller in its own file (which would 
obviously make this discussion irrelevant since mm/hugetlbcg.c would be 
dependent on your own config symbol).  I don't feel like this is the same 
as kmem since its not a global resource like hugetlb pages are.

Hugetlb pages can either be allocated statically on the command line at 
boot or dynamically via sysfs and they are globally available to whoever 
mmaps them through hugetlbfs.  I see a real benefit from being able to 
limit the number of hugepages in the global pool to a set of tasks so they 
can't overuse what has been statically or dynamically allocated.  And that 
ability should be available, in my opinion, without having to enable 
memcg, the page_cgroup metadata overhead that comes along with it, and the 
performance impact in using it.  I also think it would be wise to seperate 
it out into its own file at the source level so things like this don't 
arise in the future.

What do you think?  Kame?
--
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/