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-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
