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

[Barry Song]

On Fri, Apr 10, 2026 at 6:16 PM Matt Fleming <matt@xxxxxxxxxxxxxxxx> wrote:
>
> From: Matt Fleming <mfleming@xxxxxxxxxxxxxx>
>
> 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.

I am still struggling to understand when zram-backed
reclamation cannot make progress. Is it because zram is
full, or because folio_alloc_swap() fails?

Or does zs_malloc() fail, causing pageout() to fail?
Even incompressible pages are still written as
ZRAM_HUGE pages and reclaimed successfully.

>
> 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.

I would rather detect what causes the lack of progress
and implement a better fallback.

>
> 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@xxxxxxxxxxx>
> Signed-off-by: Matt Fleming <mfleming@xxxxxxxxxxxxxx>

Thanks
Barry