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

[David Rientjes]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/