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

[Qi Zheng <qi.zheng@linux.dev>]

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

>