Re: [PATCH for-7.5 4/5] memcg: avoid queuing high_work from reclaim

[Shakeel Butt <shakeel.butt@linux.dev>]

On Wed, Oct 14, 2026 at 01:39:06PM +0200, Michal Hocko wrote:
> On Sat 10-10-26 14:09:56, Shakeel Butt wrote:
> > Kernel threads and remote chargers use high_work when memory.high is
> > exceeded. Their allocations during reclaim can also charge memory,
> > for example when zswap stores a page.
> > 
> > Without a check, the high_work worker can queue itself from its own
> > reclaim. The pending bit is cleared before high_work runs, so each run
> > can queue another run.
> 
> What does that mean really? Does this delays the actual run?

It will not delay the actual charge request. This mainly means that we keep
enqueing the high reclaim work even from high reclaim context and can
potentially keep wasting CPU if high reclaim is not very successful.

>  
> > Skip memory.high enforcement for charges from task context with
> > PF_MEMALLOC set when they would use high_work. This covers kernel
> > threads and remote charges. The memory is still charged. Interrupt
> > charges keep their current path.
> > 
> > In a VM with incompressible zswap data, the worker queued itself 163 times
> > without this check.
> > 
> > Signed-off-by: Shakeel Butt <shakeel.butt@linux.dev>
> 
> The patch itself looks OK. I am wondering whether we can unify the check
> with the existing one which forces the allocation through in main
> charging path.

The force charge (and ENOMEM) paths bypass the memory.high enforcement
altogether. Only successful charges (done_restock label) goes through
memory.high enforcement. So, even if we move this check in try_charge_memcg, it
will still be a separate check before calling high enforcement function. I think
this check is very high_work specific and better to be in the high enforcement
function.