Re: [PATCH v2 1/1] mm: memcg: don't hand out large folios above memory.high
From: David Hildenbrand (Arm)
Date: Fri Sep 18 2026 - 10:20:55 EST
On 9/18/26 03:26, 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.
That's the same thought I had when skimming the code.
--
Cheers,
David