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/
[2] https://lore.kernel.org/lkml/6B46E8DF-679B-4254-A4AF-7B992B0F6460@nvidia.com/

--
2.43.7

This is the friendly patch-bot of Lorenzo Stoakes.

You have sent him a patch/series that has triggered this response.

He used to manually respond to these common problems, but in order to save
his sanity (he kept writing the same thing over and over, yet to different
people), I was created.

Hopefully you will not take offence and will fix the problem in your patch
and resubmit it so that it can be accepted into the Linux kernel tree.

When sending emails to mm:

1. Patch series with 1 patch sent with cover letter

Please send single patches without a cover letter.

The easiest way of accomplishing this (+ our preference) is to use
b4 [0], otherwise format patches like this:

$ git format-patch HEAD~1

[0]: https://b4.docs.kernel.org/en/latest/contributor/send.html

2. Missing cc's

You are missing cc's. Fixing this is easy with b4 [0] (the recommended way
of sending patches to mm):

$ b4 prep --auto-to-cc

Alternatively, you can use scripts/get_maintainer.pl:

$ scripts/get_maintainer.pl --nogit-fallback <files-or-patches>

[0]: https://b4.docs.kernel.org/en/latest/contributor/send.html

Specifically, the following appear to be missing:

  chrisl@kernel.org

If you wish to discuss this problem further, or you have questions about
how to resolve this issue, please feel free to respond to this email and
Lorenzo will reply once he has dug out from the pending patches received
from other developers.

thanks,

Lorenzo's patch email bot

[ Idea shamelessly stolen from greg-kh ]

--
Cheers, Lorenzo