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

[Qinyun Tan]

Hi Baolin,

On 9/4/26 2:50 PM, Baolin Wang wrote:
> 
> 
> On 9/4/26 11:54 AM, Qinyun Tan wrote:
> 
> This doesn't convince me. If the user sets defrag=defer, it means large folio allocations should not block, so using gfpflags_allow_blocking() to decide whether to call mem_cgroup_handle_over_high() is reasonable.
> 
> If you call mem_cgroup_handle_over_high() directly in the allocation functions, it would definitely increase allocation latency. This is not what we expect when setting defrag=defer.
> 
> On the other hand, I wonder if briefly exceeding memory.high is really a problem in the real products. If this is only to fix the test_memcg_high_sync selftest below, which is full of magic numbers, I don't think it makes much sense.
> 
I agree defrag expresses that the THP *allocation* should not block,
and the patch keeps the allocation path untouched.

That said, let me share a small comparison I ran, which shows what
this means for memory.high in practice.  Same kernel, one mlock(40M)
in a cgroup with memory.high=30M (no memory.max set), measuring
end-to-end mlock() time:

              no memory.high    memory.high=30M
  THP on      0.00s              2.03s
  THP off     0.01s             33.73s

With 4K pages the populate is throttled on every charge batch and
the cost scales with the overshoot -- memory.high working as
documented.  With THP, all 40M is populated unthrottled and the
entire enforcement collapses into one penalty sleep on return to
userspace, clamped at MEMCG_MAX_HIGH_DELAY_JIFFIES (2s) -- a flat
fee independent of the overshoot (a 200M mlock pays the same 2s).

So the same workload under the same memory.high gets a completely
different level of enforcement depending on the folio order of the
allocation.  That looks more like a design question than anything
else, and I'm not sure the current behavior is what we expect --
would like to hear your thoughts.

Thanks again for taking the time to review, much appreciated!

Thanks,
Qinyun Tan