Re: [PATCH v1] mm/vmscan: Add retry logic for cgroups with memory.low in kswapd

["Jiayuan Chen" <jiayuan.chen@linux.dev>]

October 16, 2025 at 22:49, "Michal Hocko" <mhocko@suse.com mailto:mhocko@suse.com?to=%22Michal%20Hocko%22%20%3Cmhocko%40suse.com%3E > wrote:


> >  
> >  Thanks Michal, let me explain the issue I encountered:
> >  
> >  1. When kswapd is triggered and there's no reclaimable memory (sc.nr_reclaimed == 0),
> >  this causes kswapd_failures counter to continuously accumulate until it reaches
> >  MAX_RECLAIM_RETRIES. This makes the kswapd thread stop running until a direct memory
> >  reclaim is triggered.
> > 
> While the definition of low limit is rather vague:
>  Best-effort memory protection. If the memory usage of a
>  cgroup is within its effective low boundary, the cgroup's
>  memory won't be reclaimed unless there is no reclaimable
>  memory available in unprotected cgroups.
>  Above the effective low boundary (or
>  effective min boundary if it is higher), pages are reclaimed
>  proportionally to the overage, reducing reclaim pressure for
>  smaller overages.
> which doesn't explicitly rule out reclaim from the kswapd context but
> historically we relied on the direct reclaim to detect the "no
> reclaimable memory" situation as it is much easier to achieve in that
> context. Also you do not really explain why backing off kswapd when all
> the reclaimable memory is low limit protected is bad.

Thanks for providing this context.


> > 
> > 2. We observed a phenomenon where kswapd is triggered by watermark_boost rather
> >  than by actual memory watermarks being insufficient. For boost-triggered
> >  reclamation, the maximum priority can only be DEF_PRIORITY - 2, making memory
> >  reclamation more difficult compared to when priority is 1.
> > 
> Do I get it right that you would like to break low limits on
> watermark_boost reclaim? I am not sure I follow your priority argument.
> 
> -- 
> Michal Hocko
> SUSE Labs
>

The issue we encountered is that since the watermark_boost parameter is enabled by
default, it causes kswapd to be woken up even when memory watermarks are still relatively
high. Due to rapid consecutive wake-ups, kswapd_failures eventually reaches MAX_RECLAIM_RETRIES,
causing kswapd to stop running, which ultimately triggers direct memory reclaim.

I believe we should choose another approach that avoids breaking the memory.low semantics.
Specifically, in cases where kswapd is woken up due to watermark_boost, we should bypass the
logic that increments kswapd_failures.