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

[Ridong Chen <ridong.chen@linux.dev>]

On 7/23/2026 4:57 PM, Barry Song wrote:
> On Thu, Jul 23, 2026 at 12:58 PM Ridong <ridong.chen@linux.dev> wrote:
>>
>> From: Ridong Chen <chenridong@xiaomi.com>
>>
>> The previous patch fixed this issue for the traditional LRU. The same
>> problem exists in MGLRU [1]: when swappiness=max (SWAPPINESS_ANON_ONLY)
>> is set, reclaim is expected to evict anonymous pages exclusively, but
>> file pages can still be reclaimed when anonymous pages cannot be
>> reclaimed (e.g. no swap and no demotion target).
>>
>> With SWAPPINESS_ANON_ONLY, get_type_to_scan() always returns
>> LRU_GEN_ANON and for_each_evictable_type() only iterates the anon type.
>> But if get_nr_to_scan() does not bail out, evict_folios() still runs and
>> isolate_folios() falls back to scanning file pages in the !scanned case:
>>
>>    shrink_one
>>      try_to_shrink_lruvec
>>        get_swappiness   // returns SWAPPINESS_ANON_ONLY for swappiness=max
>>        get_nr_to_scan
>>        evict_folios
>>          isolate_folios // falls back to file type when !scanned
>>
> 
> I am not convinced this is correct. Although we do have `type = !type`,
> when `swappiness == 201`, `for_each_evictable_type()` stops iterating
> after trying a single type, so there is no opportunity to fall back.
> 
> #define for_each_evictable_type(type, swappiness)                       \
>          for ((type) = min_type(swappiness); (type) <=
> max_type(swappiness); (type)++)
> 

You're right. In my initial version, the intention was to bail out early and 
avoid unnecessary work.

I recall that during your review of Kairui's series, you sent a patch that used 
a fallback mechanism with type = !type. I was thinking that this could become an 
issue if we call isolate_folios() when swappiness is set to max.

> So I'm really curious what's happening here.
> 
> static int isolate_folios(unsigned long nr_to_scan, struct lruvec *lruvec,
>                            struct scan_control *sc, int swappiness,
>                            struct list_head *list, int *isolated,
>                            int *isolate_type, int *isolate_scanned)
> {
>          int i;
>          int total_scanned = 0;
>          int type = get_type_to_scan(lruvec, swappiness);
> 
>          for_each_evictable_type(i, swappiness) {
>                  int scanned;
>                  int tier = get_tier_idx(lruvec, type);
> 
>                  scanned = scan_folios(nr_to_scan, lruvec, sc,
>                                        type, tier, list, isolated);
> 
>                  ...
>                  if (!scanned)
>                          type = !type;
>          }
> 
>          return total_scanned;
> }
> 
> since both min and max types are anon:
> #define min_type(swappiness) (!(swappiness))
> #define max_type(swappiness) ((swappiness) < SWAPPINESS_ANON_ONLY)
> 
> I guess the real problem only occurs when `may_swap` is false?
I added some trace logs to verify this behavior. If we don't make 
get_nr_to_scan() return 0 when swappiness=max, it won't fall back to scanning 
file pages, but it will still perform useless scanning that yields no reclaim.

Log:
   # echo "64M swappiness=max" > memory.reclaim
   [   78.914972] vmscan: in isolate_folios swappness 201
   [   78.916841] vmscan: call scan_folios type 0
   [   78.918311] vmscan: fall back 1  <-  can't call scan_folios, loop ends.
   [   78.919479] vmscan: out isolate_folios total_scanned 0
   [...]

   # cat memory.stat | grep proactive
   pgdemote_proactive 0
   pgsteal_proactive 0
   pgscan_proactive 1808

I will update the commit message to clarify that get_nr_to_scan() returns 0 to 
avoid this useless work.

-- 
Best regards
Ridong