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

["Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>]

David Rientjes <rientjes@google.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