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

Matt Fleming
2026-04-10T10:14:02Z

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.