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

[Matt Fleming <matt@readmodwrite.com>]

On Mon, Apr 13, 2026 at 05:38:19PM +0200, Vlastimil Babka (SUSE) wrote:
> 
> Hi Matt,
> 
> so have you tested it for your usecase with zram and have any observations
> how it helped, what values did you set etc?

Hey Vlastimil,

Yeah I've tested this out. So far, results have been positive -- I see
system-wide OOM kills when memory is low and direct reclaim occurs, but
not so many OOM kills that the SRE folks have started screaming at me.

I've only run with the proposed 1% value so far. I also ran a bunch of
benchmarks alongside a memory hogging app that peridoically touches
anoymous memory.

Workload                     rpp=0              rpp=1               Notes
----------------------------------------------------------------------------------------------
Kernel compile + anon hog    Completed, no OOM  Completed,          Global OOM confirmed from
                                                Global OOM fired    __alloc_pages_slowpath

Memcached + anon hog         282k / 2.30M ops/s 562k / 3.53M ops/s  Global OOM killed hog,
                             No OOM             Global OOM fired    then benchmark ran faster

Pure fio (5 reruns each)     median 3710 MiB/s  median 3702 MiB/s   No reproducible regression
Mixed fio + anon hog         2747 MiB/s         2915 MiB/s          Global OOM killed
                                                                    unrelated services

reclaim_progress_pct=1 seems to help in these memory exhausted
situations, and doesn't appear to cause a regression for the pure file
workload case.

If you have any suggestions for other tests or benchmarks to run I'd be
happy to do that.

Thanks,
Matt