On Tue, Nov 14, 2017 at 05:24:29PM +0000, Roman Gushchin wrote: > This patch implements basic accounting of memory consumption > by hugetlbfs pages for cgroup v2 memory controller. > > Cgroup v2 memory controller lacks any visibility into the > hugetlbfs memory consumption. Cgroup v1 implemented a separate > hugetlbfs controller, which provided such stats, and also > provided some control abilities. Although porting of the > hugetlbfs controller to cgroup v2 is arguable a good idea and > is outside of scope of this patch, it's very useful to have > basic stats provided by memory.stat. > > As hugetlbfs memory can easily represent a big portion of total > memory, it's important to understand who (which memcg/container) > is using it. I'm not really buying this argument. Hugetlb setups tend to be static configurations that require intimate coordination between booting the kernel with a hugetlb reservation and precisely setting up the application(s). In the few cases where you need introspection, you can check the the HugetlbPages entry in /proc/<pid>/status. The minor convenience provided by adding an aggregate cgroup counter IMO doesn't outweigh the weirdness of listing a type of resource in memory.stat that isn't otherwise acknowledged or controllable as memory. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
