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

[Kairui Song]

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.

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