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: <87ehr1xtdz.fsf@skywalker.in.ibm.com>
Date:	Thu, 03 May 2012 19:24:00 +0530
From:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
To:	David Rientjes <rientjes@...gle.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)

David Rientjes <rientjes@...gle.com> writes:

>> 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.

All the use cases I came across requested for limiting both memory
and hugetlb pages. They want to limit the usage of both. So for the use case
I am looking at memcg will already be enabled.

-aneesh

--
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/