Re: [PATCH v4 03/17] mm/memcg: add folio-based lruvec live helper

[Harry Yoo]

On Fri, Oct 16, 2026 at 02:15:59PM +0800, Kairui Song wrote:
> On Fri, Oct 16, 2026 at 3:11 AM Harry Yoo <harry@xxxxxxxxxx> wrote:
> >
> > On Fri, Oct 16, 2026 at 02:15:52AM +0800, Kairui Song via B4 Relay wrote:
> > > From: Kairui Song <kasong@xxxxxxxxxxx>
> > >
> > > Add a helper that resolves a stable lruvec for a folio under RCU
> > > without taking the lruvec lock.  It takes a folio directly so the
> > > lruvec lookup happens inside the RCU read-side critical section,
> > > which a lruvec-based interface cannot guarantee.
> > >
> > > No functional change.
> > >
> > > Tested-by: zhaozhengzhuo <zhaozhengzhuo@xxxxxxxxxxxxx>
> > > Signed-off-by: Kairui Song <kasong@xxxxxxxxxxx>
> > > ---
> >
> > This new helper is doing the the same thing as what
> > get_non_dying_memcg_start/end() do.
> >
> 
> Hi Harry, thanks for letting me know, I wasn't aware this helper
> exists, this series started before the re-planting work, so I missed
> it.

No worries!

> But it's a bit different though, get_non_dying_memcg_start assumes the
> caller holds a reference to memcg, while folio_lruvec_live_get only
> assumes the caller holds an reference to the folio.

Not sure I follow. I think get_non_dying_memcg_start() has the same
assumption (a reference to the folio). A folio no longer pins the memcg,
which was a key requirement for the reparenting work.

In the function, RCU is the only mechanism that prevents release of
the memcg and guarantees correct reparenting of local memcg stats
(state_local) as it's reparented in an RCU work.

> I'll check if I can deduplicate it though.

Thanks!

-- 
Cheers,
Harry / Hyeonggon