Re: [RFC PATCH v2] mm: vmscan: avoid anon scanning for GFP_NOIO with low swapcache in MGLRU

[Barry Song]

On Tue, Oct 27, 2026 at 1:15 PM Xiang Liu <liuxiang.277@xxxxxxxxxxxxx> wrote:
>
> Hi Barry, Baolin,
>
> Thanks for the review and discussion.
>
> I've seen the RFC v5 "mm: mglru: fix swappiness behavior" series, where
> Bo's patch 14/14 addresses the same GFP_NOIO issue on top of the new
> scan-budget model.
>
> Baolin wrote on Oct 21:
> > IMO, 'swappiness' and 'scan_swappiness' are really confusing.
>
> For a standalone v3, I plan to rename scan_swappiness to
> evict_swappiness to make its role clearer, keeping the rest of the v2
> implementation unchanged. The split in v2 preserves the original policy
> for anon aging, including the page-table walk.
>
> Barry wrote on Oct 22:
> > IMHO, this is confusing but this is a possible way to fix it before we
> > land something [...]
>
> Before preparing a v3, would a standalone fix against the current MGLRU
> code still be useful as an interim fix before the scan-budget series
> lands?

Hi Xiang,

It's a difficult question to answer. In the long term, we
hope Bo's patch 14/14 will be the final solution, but we're
not sure when it can land.

Your approach is a bit ugly, but it looks like a quick fix. we use
0 for reclamation to make sure we only reclaim file, but we use
the original swappiess for aging -  where all files and anons can be
normally aged.

 I think the real problem is that reclaimable type and swappiness
are too tightly coupled in MGLRU. In fact, they should be
orthogonal, except for swappiness=0 and swappiness=201.

Actually, the current get_swappiness() implementation has some
bugs. For example, it returns 0 when swap is full or close
to the cgroup's swap limit. But this is only a temporary
state: swap usage can drop below the limit again after
unmapping or killing processes.

However, once get_swappiness() returns 0, anon pages may
suffer from cold/hot inversion.

That's why I think we should avoid hacking get_swappiness()
any further.


>
> Or would you prefer to handle this issue through the new series? In that
> case, I can use my GFP_NOIO workload to help test Bo's patch 14/14.
>

If possible, do you think you could extract the code from
patch 14/14, even without the scan-budget-based model?
This might give us a chance to land it earlier as a
standalone change?

Best,
Barry