Re: [PATCH v3] mm: mglru: fix stale batch updates after memcg reparenting

[Qi Zheng]

On 6/27/26 1:08 AM, Shakeel Butt wrote:
> On Fri, Jun 26, 2026 at 07:21:28PM +0800, Qi Zheng wrote:
> > On 6/26/26 5:39 PM, Johannes Weiner wrote:
> > > On Fri, Jun 26, 2026 at 03:04:17PM +0800, Qi Zheng wrote:
> > > > On 6/26/26 2:48 PM, Harry Yoo wrote:
> > > > > On 6/26/26 3:24 PM, Qi Zheng wrote:
> > > > > > On 6/26/26 12:59 PM, Harry Yoo wrote:
> > > > > > > Observing a dying cgroup should be rare anyway, it's worth focusing
> > > > > > > more on readability?
> > > > > >
> > > > > > While it's rare to encounter consecutive dying memcgs, it can still
> > > > > > happen, right?
> > > > >
> > > > > But is worth saving a few instruction in a basic block that is
> > > > > unlikely() to be executed?
> > > >
> > > > I don't have a strong opinion here. Hi Johannes, I'll leave the decision
> > > > up to you. If necessary, I can send out the v4.
> > >
> > > Yes, I was thinking what Harry actually bothered to spell out ;)
> > >
> > > The race is rare, multiple levels even rarer, and even *then*
> > > mem_cgroup_lruvec() is a quick inline.
> > >
> > > This way you have one block to handle that one rare race
> > > condition. One place to put the comment. No labels, no goto.
> > >
> > > Simplicity wins :)
> >
> > Okay, I will update it as you suggested and send out the v4.
> >
> > Hi Shakeel, do we really need to move lock_batch_lruvec() to
> > memcontrol.h? It's currently only used by reset_batch_size().
>
> This function is very specific to memcg therefore I asked it move to
> memcontrol.h and not to keep in vmscan.c but we can always do the cleanup later,
> so proceed however you want.

Got it. I'll keep lock_batch_lruvec() in vmscan.c for now. Once there is
a second caller, we can clean it up and move it to memcontrol.h.

Thanks,
Qi

>