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

[Shakeel Butt]

On Tue, Sep 15, 2026 at 12:25:46PM +0800, Qinyun Tan wrote:
> memory.high is enforced on return to userspace, and synchronously in

Over time I feel like this sync throttle for memory.high was a bad decision but
that is an orthogonal discussion.

> try_charge_memcg() for large overcharges, but only when the charge gfp
> allows blocking.  A populate loop - mlock(), MADV_POPULATE_*, any
> GUP-driven population - never returns to userspace, and large folios are
> charged with the THP allocation gfp, which does not allow blocking under
> the default defrag=madvise without MADV_HUGEPAGE, nor under defrag=defer.
> So neither runs: usage grows from memory.high straight up to memory.max
> with no reclaim and no penalty sleep.
> 
> mlock(200M) in a cgroup with memory.high=30M and memory.max=140M.  Of the
> 110M between high and max, the burst consumed:
> 
>   4K pages                       3M in 5s, then still throttled
>   THP, defrag=always             6M in 5s, then still throttled
>   THP, defrag=madvise          110M in 13ms, then OOM killed at 16ms
>   THP, defrag=madvise, patched   3M in 5s, then still throttled

I don't really like polluting non-memcg MM code with memcg internal details.
Let's first discuss the semantics we want here. Please tell why getting
oom-killed by kernel in the scenario you have described (mlock() larger than
memory.max) is wrong. How does throttling it will help? What can the external
observer (userspace oom-killer) do other than killing it? Or you are thinking
that the workload itself is observing itself and change the behavior (though
the big mlock one can't do anything).

What I am looking for is the real use-case you have for this case. Not
mlock()ing big chunk or creating a lot of unreclaimable memory and going over
memory.high. For example the reason I added the sync throttle in memory.high was
to implement a feature Google has in their internal kernel where a workload hits
its memory.max limit, kernel delays the kill for couple of seconds and during
that time, the node controller may decide to increase the limit based on the
memory situation of the memory. However even with sync throttle, we couldn't
reliably implement the alternative because applications there have thousands of
threads and there is threading library which keeps cloning more threads if it
observes threads getting throttled.

So, let's talk about some real use-case and then we can decide if throttling
makes sense here. If we decide to allow throttling in such cases, I would rather
do it in memcg code i.e. somehow inform memcg code that this is THP allocation
and can be throttled.