Re: [PATCH v3 2/6] mm/mglru: introduce helpers for manipulating gen and refs flags

[Kairui Song]

On Sun, Aug 30, 2026 at 04:39:33PM +0800, Ridong Chen wrote:
> 
> 
> On 8/26/2026 1:53 AM, Kairui Song via B4 Relay wrote:
> > From: Kairui Song <kasong@xxxxxxxxxxx>
> > 
> > Instead of doing bit ops on folio->flags.f, introduce helpers for
> > adjusting a folio's refs and generation info, making the code easier
> > to debug and understand.
> > 
> > No functional change is intended: some combined atomic operations are
> > split into two, which only creates harmless transient states. There is
> > no measurable performance impact, and some paths even look slightly
> > better in the generated assembly.
> > 
> > Signed-off-by: Kairui Song <kasong@xxxxxxxxxxx>
> > ---
> >   include/linux/mm_inline.h | 76 ++++++++++++++++++++++++++++++++++++++++++-----
> >   include/linux/mmzone.h    |  1 +
> >   mm/folio.c                | 19 +++++++-----
> >   mm/vmscan.c               | 61 ++++++++++++++++++++-----------------
> >   4 files changed, 114 insertions(+), 43 deletions(-)
> > 

...

> > diff --git a/mm/folio.c b/mm/folio.c
> > index c02dcea9c03c..a932059057ac 100644
> > --- a/mm/folio.c
> > +++ b/mm/folio.c
> > @@ -353,26 +353,28 @@ static void __lru_cache_activate_folio(struct folio *folio)
> >   static void lru_gen_inc_refs(struct folio *folio)
> >   {
> > -	unsigned long new_flags, old_flags = READ_ONCE(folio->flags.f);
> > +	unsigned long new_flags, old_flags = READ_ONCE(*folio_flags(folio, 0));
> > +	int refs;
> >   	if (folio_test_unevictable(folio))
> >   		return;
> >   	/* see the comment on LRU_REFS_FLAGS */
> > -	if (!folio_test_referenced(folio)) {
> > -		set_mask_bits(&folio->flags.f, LRU_REFS_MASK, BIT(PG_referenced));
> > +	if (!folio_lru_refs(folio)) {
> > +		folio_set_lru_refs(folio, 1);
> >   		return;
> >   	}
> 
> Do we still need this branch now?
> 
> If folio_lru_refs(folio) == 0, that means refs =
> lru_refs_from_flags(old_flags) == 0, correct?
> 
> If so, the do-while loop below already handles this case, making this early
> return redundant.
> 
> Or am I missing something here?

You are right, it can be optimized. And that's is not the only part can be
optimized after the cleanup I think. But perhaps optimization can come
later? The helper convertion will be harder to review if mixed with
optimization I think.