Re: [PATCH 3/6] mm/mglru: enhance cold/hot inversion handling in inc_min_seq()

[Baoquan He <baoquan.he@linux.dev>]

On 08/27/26 at 10:14am, Baoquan He wrote:
> On 08/27/26 at 09:24am, Barry Song wrote:
> > On Thu, Aug 27, 2026 at 8:46 AM Baoquan He <baoquan.he@linux.dev> wrote:
> > >
> > > On 08/27/26 at 05:43am, Barry Song wrote:
> > > > On Wed, Aug 26, 2026 at 4:56 PM Baoquan He <baoquan.he@linux.dev> wrote:
> > > > >
> > > > > On 08/21/26 at 06:25pm, Barry Song (Xiaomi) wrote:
> > > > > > During aging, a folio's generation may already have been updated by
> > > > > > folio_update_gen(), even though it has not yet been moved to the
> > > > > > corresponding generation list. Such folios are hotter than those
> > > > > > already in that generation.
> > > > > >
> > > > > > It makes sense for inc_min_seq() to increment the generation of
> > > > > > folios that were never promoted during aging and move them to the
> > > > > > tail of the new oldest generation. However, folios that were already
> > > > > > promoted should instead be moved to the head of their updated
> > > > > > generation, just as sort_folio() does in scan_folios().
> > > > >
> > > > > While sort_folio() move protected folio to the head of next gen too.
> > > > > It only moves ineligible folios to the tail of next gen.
> > > > >
> > > >
> > > > Hi Baoquan,
> > > >
> > > > Thanks for the review! I’m not quite sure I understand what you mean :-)
> > > > Could you please clarify what you’re suggesting?
> > >
> > > Sorry for the confusion, Barry. I meant this is a good one, and
> > > sort_folio() has the similar issue in which the protected folios are
> > > moved to the head, wondering if that need be adjusted too. One consistent
> > > rule for both is better.
> > 
> > I think it might be fine for sort_folio() to move protected folios to the
> > head, since those folios have either been accessed multiple times or have
> > reached a tier higher than tier_idx. They are sort of hot in theory, right?
> > 
> > if (tier > tier_idx || refs + workingset == BIT(LRU_REFS_WIDTH) + 1)
> > 
> > But for inc_min_seq(), it is just catching up to make sure the newest
> > generation doesn't overlap with the oldest generation. Those non-promoted
> > folios themselves aren't hot , so I feel these are actually different?
> 
> I got your point, sort_folio() considers the hottness, inc_min_seq()
> doesn't. I agree with you now. Thanks for the explanation.
> 
> BUT no matter what it is, protected folios, lazily promoted folios,
> and no matter where it is, put in head of next gen or tail of next gen,
> their refs are cleared by folio_inc_gen(). Then in sort_folio(), they
> are all tier 0 of the oldest gen and must be reclaimed.

Or mm walking will take a long time, it doesn't matter much about the
refs in next gen in inc_min_seq() because there are a lot of chances
refs are updated when it comes to sort_folio()?

> 
> So here, I think differentiating them and moving them into head or tail
> doesn't make sense, the thing is whether if we need do something to
> retain refs of folios when gen_increased. At least, for lazily promoted
> folios, it should not be put in the tail of next gen and refs cleared.
> What do you think?
> 
> Thanks
> Baoquan