Re: [PATCH] mm: Require LRU reclaim progress before retrying direct reclaim

[Pedro Falcato]

On Thu, Apr 16, 2026 at 02:49:28PM -0700, Shakeel Butt wrote:
> On Thu, Apr 16, 2026 at 03:51:04PM +0100, Matt Fleming wrote:
> > On Wed, Apr 15, 2026 at 03:57:25PM +0100, Pedro Falcato wrote:
> [...]
> > 
> > > My theory (from merely reading the patch, maybe I missed something) is that
> > > a pathological case for this is a lot of folios added to the LRU in a row,
> > > that are set referenced (or dirty). Say SWAP_CLUSTER_MAX * MAX_RECLAIM_RETRIES
> > > - it will simply OOM too early.
> >  
> > OK yeah I think I see the problem now: this heuristic applies the
> > threshold against all reclaimable pages but that falls apart when doing
> > SWAP_CLUSTER_MAX chunks of reclaim.
> 
> I am not sure I understand the pathological case. Yes SWAP_CLUSTER_MAX is
> requested amount of pages to reclaim but the kernel can potentially scan full
> memory twice to reclaim that much amount. Though those reclaimed pages can get
> stolen but that can still happen today before this patch.

I see, yes, you are totally correct. Had a look at the vmscan code again and just
realized I had missed some details.

Matt, please disregard :)

-- 
Pedro