Changelog: v4: * Add another prep patch to clean up memory controller migration logic. * Fix an issue in hugetlb folio migration where the new folio is not properly charged (patch 3) (reported by Mike Kravetz) (suggested by Johannes Weiner). v3: * Add a prep patch at the start of the series to extend the memory controller interface with new helper functions for hugetlb accounting. * Do not account hugetlb memory for memcontroller in cgroup v1 (patch 2) (suggested by Johannes Weiner). * Change the gfp flag passed to mem cgroup charging (patch 2) (suggested by Michal Hocko). * Add caveats to cgroup admin guide and commit changelog (patch 2) (suggested by Michal Hocko). v2: * Add a cgroup mount option to enable/disable the new hugetlb memcg accounting behavior (patch 1) (suggested by Johannes Weiner). * Add a couple more ksft_print_msg() on error to aid debugging when the selftest fails. (patch 2) Currently, hugetlb memory usage is not acounted for in the memory controller, which could lead to memory overprotection for cgroups with hugetlb-backed memory. This has been observed in our production system. For instance, here is one of our usecases: suppose there are two 32G containers. The machine is booted with hugetlb_cma=6G, and each container may or may not use up to 3 gigantic page, depending on the workload within it. The rest is anon, cache, slab, etc. We can set the hugetlb cgroup limit of each cgroup to 3G to enforce hugetlb fairness. But it is very difficult to configure memory.max to keep overall consumption, including anon, cache, slab etc. fair. What we have had to resort to is to constantly poll hugetlb usage and readjust memory.max. Similar procedure is done to other memory limits (memory.low for e.g). However, this is rather cumbersome and buggy. Furthermore, when there is a delay in memory limits correction, (for e.g when hugetlb usage changes within consecutive runs of the userspace agent), the system could be in an over/underprotected state. This patch series rectifies this issue by charging the memcg when the hugetlb folio is allocated, and uncharging when the folio is freed. In addition, a new selftest is added to demonstrate and verify this new behavior. Nhat Pham (4): memcontrol: add helpers for hugetlb memcg accounting memcontrol: only transfer the memcg data for migration hugetlb: memcg: account hugetlb-backed memory in memory controller selftests: add a selftest to verify hugetlb usage in memcg Documentation/admin-guide/cgroup-v2.rst | 29 +++ MAINTAINERS | 2 + include/linux/cgroup-defs.h | 5 + include/linux/memcontrol.h | 37 +++ kernel/cgroup/cgroup.c | 15 +- mm/filemap.c | 2 +- mm/hugetlb.c | 35 ++- mm/memcontrol.c | 139 +++++++++-- mm/migrate.c | 3 +- tools/testing/selftests/cgroup/.gitignore | 1 + tools/testing/selftests/cgroup/Makefile | 2 + .../selftests/cgroup/test_hugetlb_memcg.c | 234 ++++++++++++++++++ 12 files changed, 478 insertions(+), 26 deletions(-) create mode 100644 tools/testing/selftests/cgroup/test_hugetlb_memcg.c -- 2.34.1
