Re: [PATCH 0/3] mm/mglru: clean up isolate_folios and scan_folios for readability and clarity

[Baolin Wang]

On 8/24/26 7:05 PM, Kairui Song wrote:
> On Mon, Aug 24, 2026 at 3:25 PM Baolin Wang
> <baolin.wang@xxxxxxxxxxxxxxxxx> wrote:
> > On 8/20/26 12:56 PM, Barry Song (Xiaomi) wrote:
> > > This is a cleanup series split out from the MGLRU swappiness series [1],
> > > with the cleanup changes separated to make them easier to review.
> > >
> > > Right now, isolate_folios() is quite difficult to follow:
> > >
> > > 1. It uses for_each_evictable_type(i, swappiness) to iterate over the
> > > types, but i is not actually used as the type within the loop body.
> > >
> > > 2. It uses scanned == 0 to detect whether the current reclaim type is
> > > exhausted, but this is not an accurate indication.
> > >
> > > 3. It has an internal retry when no folios can be isolated after scanning
> > > some folios, but the retry is implemented in a way nobody can understand.
> > >
> > > This patchset makes these behaviors explicit and much easier to follow.
> > >
> > > Run kernel builds for several rounds in a 1 GB memcg and take the
> > > average build time. The patchset shows almost no performance impact,
> > > with a very small improvement that could simply be noise:
> >
> > Just FYI:
> >
> > I tested this patchset with a 3G memcg limit and a 10G zram device,
> > running 'make -j32' to build kernel on my 32-core Arm machines, and got
> > some performance improvement for ths sys time:
> >          w/o patch       w/patch
> > sys     1845s           1570s
>
> Hi Baoliln
>
> That's a very interesting result, can you share a bit more info about
> it? e.g. vmstat? I'm curious how this happens.

Sure.

> I suspect patch 2 or 3 changes the swappiness / reclaim / aging type
> selection behavior, or maybe it reduced the reclaim amount?

I gathered the memcg stats as shown below.

It looks like the direct reason for the performance improvement is an 
obvious reduction in anon refaults, which is what this patch aims to 
achieve I think. That is to say, we should respect the type chosen by 
the PID for reclaim, and try to exhaust that type before falling back to 
another.

Before this series:
workingset_refault_anon 59706846
workingset_refault_file 9229283
workingset_activate_anon 15108561
workingset_activate_file 365660
workingset_restore_anon 15108561
workingset_restore_file 1018493
workingset_nodereclaim 0
pgsteal_kswapd 0
pgsteal_direct 92589340
pgsteal_khugepaged 549
pgsteal_proactive 0
pgscan_kswapd 0
pgscan_direct 456629355
pgscan_khugepaged 549

After this series:
workingset_refault_anon 41277086
workingset_refault_file 9131522
workingset_activate_anon 12924656
workingset_activate_file 345901
workingset_restore_anon 12924656
workingset_restore_file 1005959
workingset_nodereclaim 0
pgsteal_kswapd 0
pgsteal_direct 71723800
pgsteal_khugepaged 4013
pgsteal_proactive 0
pgscan_kswapd 0
pgscan_direct 342179445
pgscan_khugepaged 9311