lkml.org 
[lkml]   [2012]   [May]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: inux-next: Tree for Apr 27 (uml + mm/memcontrol.c)
Date
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



\
 
 \ /
  Last update: 2012-05-03 16:01    [from the cache]
©2003-2011 Jasper Spaans