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

[Qinyun Tan <qinyuntan@linux.alibaba.com>]

On 9/18/26 9:26 AM, Shakeel Butt wrote:
> 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.

Hi Shakeel,

Thanks for the detailed review.

Honestly I don't have a real use-case. I ran into this while testing THP
under memory.high, so it's a semantic inconsistency I noticed rather than
a workload I'm fixing. 

The thing that seemed off is just that memory.high enforcement depends on
the folio order the workload happens to fault in - order-0 gets
throttled, THP under the default THP settings doesn't - which the user
has no control over. 

I don't have a firm view on the right semantics here either, and I think
you're right that that's the thing to pin down first. Whether the
order-dependence above is worth doing something about, or whether it's
acceptable for large folios to skip memory.high, I don't have a strong
opinion on - I'm happy to go with whatever the discussion settles on, and
if it's working as intended, that's just as useful to know.

And if it does turn out to be worth throttling, I'd be happy to rework it.

Thanks,
Qinyun Tan