Re: [PATCH RFC 10/15] mm/mglru: make folio lru referenced times count a generic API

Kairui Song <[email protected]> Tue, 4 Aug 2026 17:02:14 +0800
Newsgroups org.kernel.vger.cgroups,org.kernel.vger.linux-kernel
Message-ID <CAMgjq7Au8ApkQM9t12WcX3VREb2Xpa8o+KDKK4A4bDtzhjr36A@mail.gmail.com>
On Tue, Aug 4, 2026 at 3:49=E2=80=AFPM Lian Wang <[email protected]> wrot=
e:
>
> From: "Lian Wang (ProcessMission)" <[email protected]>
>
> Hi Kairui,
>
> I am trying to understand the intended semantics of making the referenced
> count a generic API, and would appreciate your guidance. My understanding=
 is
> that, with the new encoding, raw PG_referenced and PG_workingset users no
> longer see simple boolean states for every reference count.

Hello Lian

Yes exactly, actually the first thing come to my mind is DAMON. Now
folio_inc_lru_refs seems a good way for DAMON to feedback hotness info
to MGLRU? It track the referenced total number count, and handles
promotion and refs overflow internally, and affects PID nicely. We
don't have a similiar interface before, folio_mark_access doesn't work
well for MGLRU for this case as it has very limited effect, only work
through PID feedback.

>
> A few examples I found:
>
> - damon_pa_pageout() still calls folio_clear_referenced(). With refs =3D=
=3D 2 it
>   clears nothing, and with refs =3D=3D 3 it leaves refs =3D=3D 2. Thus DA=
MOS pageout
>   may retain workingset history instead of clearing the MGLRU reference s=
tate.

Right I have a patch before:
https://lore.kernel.org/linux-mm/20260502-mglru-fg-v1-20-913619b014d9@tence=
nt.com/

Just didn't include it this time, series is getting too long...

> - EROFS zdata uses PageWorkingset() for PSI accounting. With the new enco=
ding,
>   the PG_workingset bit is clear for refs =3D=3D 4 or 5 even though the f=
olio is
>   hot.
> - /proc/kpageflags exports PG_referenced directly, so KPF_REFERENCED appe=
ars
>   to become the parity of refs rather than a boolean referenced state.
>
> Are these semantics intended? The DAMON case in particular looks similar =
to
> the madvise conversion in patch 15. If my understanding is correct, would=
 the
> remaining raw-bit users need a tree-wide audit together with the API
> conversion?

I think most existing workingset / referenced bit user can just
transparently transfer to the new layout if I change
folio_test_workingset itself instead of conver the users one by one,
and my bad I forgot the EROFS case this time :), will fix in v2, I did
convert BTRFS though:
https://lore.kernel.org/linux-mm/20260804-mglru-fg-v1-11-4d8dad39dad6@tence=
nt.com/T/#Z2e.:..:20260804-mglru-fg-v1-11-4d8dad39dad6::40tencent.com:1fs:b=
trfs:compression.c

And MGLRU's previous PG_workinset certerial is very different from
CLRU and is already causing inaccurate reading of PSI, the new design
actually aligned the PG_workingset defination with CLRU. For
PG_referenced, I actually don't think that flag was really useful
before, because it constantly gets unset / set as the folio is moved
betweet active / inactive for CLRU. The new layout still mostly aligns
with the existing MGLRU design for that referenced flag, and I think
it's clearer now: once a folio is ever seen referenced, the flag
remains and won't disappear (unless some user explicitly needs to
reset refs for some reason). And refaulted folios are definitely
referenced unless they are readahead, and we can try reporting
readahead folios as not referenced if necessary.

>
> If I have misunderstood how these users are expected to behave, please fe=
el
> free to ignore these concerns.
>
> Thanks,
> Lian
>
> On Tue, 04 Aug 2026 03:47:06 +0800 Kairui Song via B4 Relay <devnull+kaso=
[email protected]> wrote:
>
...

BTW I suggest you to trim the tailing part on reply, that will make it
easier for others to read the mail :)