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

On Thu, Aug 20, 2026 at 09:43:38AM +0800, Ridong Chen wrote:
> 
> 
> On 8/18/2026 1:38 PM, Kairui Song via B4 Relay wrote:
> > From: Kairui Song <[email protected]>
> > 
> > Instead of doing bit ops on folio->flags.f, introduce helpers for
> > adjusting folio's refs and gen info, make 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.
> > 
> > Signed-off-by: Kairui Song <[email protected]>
> > ---
> >   include/linux/mm_inline.h | 79 +++++++++++++++++++++++++++++++++++++++++------
> >   include/linux/mmzone.h    |  2 ++
> >   mm/folio.c                | 19 +++++++-----
> >   mm/vmscan.c               | 61 ++++++++++++++++++++----------------
> >   4 files changed, 117 insertions(+), 44 deletions(-)
> > 
> > diff --git a/include/linux/mm_inline.h b/include/linux/mm_inline.h
> > index 621c8653d8f7..93bf3fa221f8 100644
> > --- a/include/linux/mm_inline.h
> > +++ b/include/linux/mm_inline.h
> > @@ -142,10 +142,43 @@ static inline int lru_tier_from_refs(int refs, bool workingset)
> >   	return workingset ? MAX_NR_TIERS - 1 : order_base_2(refs);
> >   }
> > -static inline int folio_lru_refs(const struct folio *folio)
> > +/**
> > + * lru_gen_from_flags - Return the LRU generation number from folio flags.
> > + * @flags: folio flags
> > + *
> > + * Returns: A number between 0 and LRU_GEN_MAX, inclusive. Returns -1 if the
> > + * flags indicate the folio is off the list (e.g., isolated).
> > + */
> > +static inline int lru_gen_from_flags(unsigned long flags)
> > +{
> > +	int gen = ((flags & LRU_GEN_MASK) >> LRU_GEN_PGOFF);
> > +
> > +	BUILD_BUG_ON(LRU_GEN_MASK & LRU_REFS_MASK);
> > +	gen -= 1;
> > +	VM_WARN_ON_ONCE(gen != -1 && gen > LRU_GEN_MAX);
> 
> Perhaps we could define a macro such as GEN_OFF = -1 to make the code more
> self-explanatory, I found this warning a bit confusing at first glance.
> 
> LRU_GEN_MAX already bears some resemblance to MAX_NR_GENS, so introducing
> yet another macro may add some clutter.
> 
> Just my two cents.
> 

Thanks for the review.

Let me just simplify the sanity check then, I think using MAX_NR_GENS are
good engough.