Re: [PATCH 1/2] mm: memcg: settle memory.high debt after THP faults with non-blocking gfp

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

On 9/4/26 11:10 PM, Zi Yan wrote:
> On 3 Sep 2026, at 23:54, Qinyun Tan wrote:
> 
>> Anonymous THP faults happening in a kernel loop that does not return
>> to userspace -- the populate loop of a single mlock() call, or any
>> GUP-driven population -- can drive a memcg's usage from memory.high
>> all the way up to memory.max with zero reclaim and zero penalty
>> sleep.
>>
>> This defeats the containment memory.high is supposed to provide:
>> above high, the documented promise is that "the processes of the
>> cgroup are throttled and put under heavy reclaim pressure", and
>> userspace OOM handlers (oomd, Kubernetes) rely on the high..max
>> buffer as their reaction window.  Only after hitting memory.max does
>> the non-blocking charge fail, THP fall back to 4K, and
> 
> Why not force THP to fall back to 4KB when memory.high is reached?
> If reaching memory.high means the processes are under heavy reclaim
> pressure, I do not think it is reasonable to give any more THP.
> 

Hi Zi Yan,

Thanks for the review.

I think you're right that this is a policy question. Falling back
to 4K at memory.high is also workable -- it would even be simpler,
and the existing fallback machinery would take care of the rest.
I picked settling the debt mainly to keep memory.high a soft limit
for all folio sizes, but I don't feel strongly about it. 

I'd be curious to hear what others think here -- happy to rework the
series either way.