[PATCH v2 0/1] mm: memcg: don't hand out large folios above memory.high

memory.high is enforced at two points after a charge succeeds: on
return to userspace, and synchronously in try_charge_memcg() for
large overcharges, the latter gated on gfpflags_allow_blocking().

The THP fault paths pass the physical allocation gfp from
vma_thp_gfp_mask() to the memcg charge.  With the default
defrag=madvise (and no MADV_HUGEPAGE), as well as with defrag=defer,
that gfp does not allow blocking, so inside a single-syscall populate
loop - mlock(), MADV_POPULATE_*, any GUP-driven population - neither
enforcement point runs: usage grows from memory.high straight up to
memory.max with no reclaim and no penalty sleep, consuming the
reaction window that userspace OOM handlers (oomd, Kubernetes) depend
on.

v1 [1] settled the accrued over-high debt from the fault paths after
each non-blocking large folio charge.  As Zi Yan pointed out in his
review [2], falling back to order-0 above memory.high is the better
answer: above high the cgroup is meant to be under heavy reclaim
pressure, and the order-0 fallback's charge blocks, so it is throttled
synchronously as is.  v2 does that instead, and is a single patch now.

Qinyun Tan (1):
  mm: memcg: don't hand out large folios above memory.high

 include/linux/memcontrol.h | 33 ++++++++++++++++++++++
 mm/huge_memory.c           | 12 ++++++++
 mm/memcontrol.c            | 56 ++++++++++++++++++++++++++++++++++++++
 mm/memory.c                |  7 ++++++
 mm/swap_state.c            | 16 ++++++++++-
 5 files changed, 123 insertions(+), 1 deletion(-)

[1] https://lore.kernel.org/lkml/20260904035407.4098627-1-qinyuntan@linux.alibaba.com/ (local)
[2] https://lore.kernel.org/lkml/6B46E8DF-679B-4254-A4AF-7B992B0F6460@nvidia.com/ (local)

--
2.43.7