Re: [PATCH -v4 1/4] mm/vmscan: fix anon-only reclaim evicting file pages when swappiness=max

[Barry Song]

On Tue, Jul 28, 2026 at 3:18 PM Michal Hocko <mhocko@xxxxxxxx> wrote:
>
[...]
> > >
> > > Looking at how the code is structured currently doesn't the following
> > > express the intention slightly better?
> > >
> > > diff --git a/mm/vmscan.c b/mm/vmscan.c
> > > index 35c3bb15ae96..4fd38e3f1b05 100644
> > > --- a/mm/vmscan.c
> > > +++ b/mm/vmscan.c
> > > @@ -2503,6 +2503,10 @@ static void get_scan_count(struct lruvec *lruvec, struct scan_control *sc,
> > >
> > >         /* If we have no swap space, do not bother scanning anon folios. */
> > >         if (!sc->may_swap || !can_reclaim_anon_pages(memcg, pgdat->node_id, sc)) {
> > > +               if (swappiness == SWAPPINESS_ANON_ONLY && sc->proactive) {
> > > +                       memset(nr, 0, sizeof(*nr) * NR_LRU_LISTS);
> > > +                       return;
> > > +               }
> > >                 scan_balance = SCAN_FILE;
> >
> > The question is whether we should allow falling back to SCAN_FILE
> > when swappiness == SWAPPINESS_ANON_ONLY and !sc->proactive, if 201 is
> > ever allowed for non-proactive reclaim in the future. I guess not,
> > since SWAPPINESS_ANON_ONLY literally means reclaiming anonymous
> > memory only?
>
> If we follow swappiness==0 then yes we should fallback if we are close
> to system OOM. Now arguably SWAPPINESS_ANON_ONLY is a wierd global

SWAPPINESS_ANON_ONLY with swappiness=201 is a rather odd
interface. I suspect it was introduced as a workaround for
MGLRU's swappiness behavior, where swappiness=200 can still
result in significant file reclaim (not much different from
swappiness=60 or 100), while the active/inactive LRU
reclaims few or no file folios.
So `201` was introduced to prevent MGLRU from reclaiming file
folios by bypassing the file reclaim path?

Qi, please correct me if I'm wrong. :-) If it serves a purpose
beyond this, even for the active/inactive LRU, please let me
know.

I'm working on addressing mglru swappiness issue:
https://lore.kernel.org/linux-mm/20260726122123.7614-1-baohua@xxxxxxxxxx/

With my patchset, `swappiness=200` under MGLRU reclaims very
few file folios, similar to the active/inactive LRU. If that
works well, I suspect we may be able to drop the special
`201` value in the future.

> policy and it is quite possible this will not be ever allowed. My
> argument was not to prepare the existing code for that. I just meant to
> structure the code in a way that it current assumptions are more
> explicit.

I understand your point. I just find

    if (swappiness == SWAPPINESS_ANON_ONLY && sc->proactive)

a bit odd, since `swappiness == SWAPPINESS_ANON_ONLY`
already implies `sc->proactive`.

So maybe:

        if (!sc->may_swap || !can_reclaim_anon_pages(memcg,
pgdat->node_id, sc)) {
 +               if (swappiness == SWAPPINESS_ANON_ONLY) {
 +                       WARN_ON_ONCE(!sc->proactive);
 +                       memset(nr, 0, sizeof(*nr) * NR_LRU_LISTS);
 +                       return;
 +               }

?

Best Regards
Barry