Message-Id: <20231006184629.155543-1-nphamcs@gmail.com>
Date:   Fri,  6 Oct 2023 11:46:25 -0700
From:   Nhat Pham <nphamcs@...il.com>
To:     akpm@...ux-foundation.org
Cc:     riel@...riel.com, hannes@...xchg.org, mhocko@...nel.org,
        roman.gushchin@...ux.dev, shakeelb@...gle.com,
        muchun.song@...ux.dev, tj@...nel.org, lizefan.x@...edance.com,
        shuah@...nel.org, mike.kravetz@...cle.com, yosryahmed@...gle.com,
        fvdl@...gle.com, linux-mm@...ck.org, kernel-team@...a.com,
        linux-kernel@...r.kernel.org, cgroups@...r.kernel.org
Subject: [PATCH v4 0/4] hugetlb memcg accounting

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

Powered by blists - more mailing lists