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

[Matt Fleming <mfleming@cloudflare.com>]

On Fri, Apr 10, 2026 at 10:41:56AM +0100, Matt Fleming wrote:
> From: Matt Fleming <mfleming@cloudflare.com>
> 
> should_reclaim_retry() uses zone_reclaimable_pages() to estimate whether
> retrying reclaim could eventually satisfy an allocation. It's possible
> for reclaim to make minimal or no progress on an LRU type despite having
> ample reclaimable pages, e.g. anonymous pages when the only swap is
> RAM-backed (zram). This can cause the reclaim path to loop indefinitely.
> 
> Track LRU reclaim progress (anon vs file) through a new struct
> reclaim_progress passed out of try_to_free_pages(), and only count a
> type's reclaimable pages if at least reclaim_progress_pct% was actually
> reclaimed in the last cycle.
> 
> The threshold is exposed as /proc/sys/vm/reclaim_progress_pct (default
> 1, range 0-100). Setting 0 disables the gate and restores the previous
> behaviour. Environments with only RAM-backed swap (zram) and small
> memory may need a higher value to prevent futile anon LRU churn from
> keeping the allocator spinning.
> 
> Suggested-by: Johannes Weiner <hannes@cmpxchg.org>
> Signed-off-by: Matt Fleming <mfleming@cloudflare.com>
> ---
>  include/linux/swap.h |  13 +++++-
>  mm/page_alloc.c      | 101 +++++++++++++++++++++++++++++++++++--------
>  mm/vmscan.c          |  72 ++++++++++++++++++++++--------
>  3 files changed, 146 insertions(+), 40 deletions(-)

Whoops, I fat-fingered this and sent it as a reply. I'll send it again
as a separate patch. My bad.