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