Re: [PATCH v4] mm: vmscan: avoid anon scanning for GFP_NOIO with low swapcache

[Andrew Morton]

On Tue,  8 Sep 2026 14:26:49 +0800 Bo Zhang <zhangbo0325@xxxxxxxxx> wrote:

> We have observed some cases where memory is allocated with GFP_NOIO, so
> we cannot reclaim any anon folios unless they are in swapcache. We can
> end up spending more than 150 ms looping in `shrink_folio_list()` scanning
> non-swapcache folios without reclaiming a single folio. This is pure
> overhead.
> 
> This is particularly true on systems using zRAM, where swapcache is
> relatively rare. So let's check whether anon reclaim is allowed by
> GFP_IO and whether there is enough swapcache to make it worthwhile. If
> the swapcache is extremely low, we're essentially searching for a
> needle in a haystack, so let's avoid scanning anon in the first place.
> 
> On Android this is triggered by dm-verity hash-block reads through
> dm-bufio, which legitimately use GFP_NOIO because they run underneath the
> IO path:
> 
> ...
>
> To stay conservative, this only skips anon when the swapcache is really
> tiny - below 1/64 of the anon LRU - i.e. when essentially no anon on the
> list can be reclaimed without IO. Whenever there is a meaningful amount of
> swapcached anon, the normal path is used and anon is scanned and aged as
> before.
> 
> ...
>

OK, thanks, I'll add this for testing and more review.

With trepidation.  It's easy to play whack-a-mole with this code:
improve one thing, worsen another.  Unfortunately the "improve" step is
apparent immediately whereas "worsen" can take years.

So, as I said, testing and more review.