Re: [linus:master] [mm] 01b9da291c: stress-ng.switch.ops_per_sec 67.7% regression

On 5/13/26 10:27 PM, Shakeel Butt wrote:
> On Wed, May 13, 2026 at 06:49:45AM -0700, Shakeel Butt wrote:
>> On Wed, May 13, 2026 at 10:10:34AM +0800, Qi Zheng wrote:
>>>
>>>
>>> On 5/13/26 12:03 AM, Shakeel Butt wrote:
>>>> On Tue, May 12, 2026 at 08:56:52PM +0800, kernel test robot wrote:
>>>>>
>>>>>
>>>>> Hello,
>>>>>
>>>>> kernel test robot noticed a 67.7% regression of stress-ng.switch.ops_per_sec on:
>>>>>
>>>>>
>>>>> commit: 01b9da291c4969354807b52956f4aae1f41b4924 ("mm: memcontrol: convert objcg to be per-memcg per-node type")
>>>>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
>>>>
>>>> This is most probably due to shuffling of struct mem_cgroup and struct
>>>> mem_cgroup_per_node members.
>>>
>>> Another possibility is that after objcg was split into per-node, the
>>> slab accounting fast path is still designed assuming only one current
>>> objcg per CPU:
>>>
>>> struct obj_stock_pcp {
>>>      struct obj_cgroup *cached_objcg;
>>> };
>>>
>>> So it's may cause the following thrashing:
>>>
>>>   CPU stock cached = memcg/node0 objcg
>>>   free object tagged = memcg/node1 objcg
>>>   => __refill_obj_stock --> objcg mismatch
>>>       => drain_obj_stock()
>>>       => cache switches to node1 objcg
>>>
>>>   next local allocation tagged = node0 objcg
>>>   => mismatch again
>>>       => drain_obj_stock()
>>
>> Actually I think this is the issue, we have ping pong threads running on
>> different nodes where though theu are in same cgroup but their current->obcg is
>> for local node and thus this ping pong is thrashing the per-cpu objcg stock.
>>
>> The easier fix would be to compare objcg->memcg instead of just objcg during
>> draining and caching. In addition we can add support for multiple objcg per-cpu
>> stock caching.
> 
> Something like the following:
> 
>  From d756abe831a905d6fe32bad9a984fc619dafb7e0 Mon Sep 17 00:00:00 2001
> From: Shakeel Butt <[email protected]>
> Date: Wed, 13 May 2026 07:24:55 -0700
> Subject: [PATCH] mm/memcontrol: skip obj_stock drain when refilled objcg
>   shares memcg
> 
> Signed-off-by: Shakeel Butt <[email protected]>
> ---
>   mm/memcontrol.c | 14 +++++++++++++-
>   1 file changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/mm/memcontrol.c b/mm/memcontrol.c
> index d978e18b9b2d..01ed7a8e18ac 100644
> --- a/mm/memcontrol.c
> +++ b/mm/memcontrol.c
> @@ -3318,6 +3318,7 @@ static void __refill_obj_stock(struct obj_cgroup *objcg,
>   			       unsigned int nr_bytes,
>   			       bool allow_uncharge)
>   {
> +	struct obj_cgroup *cached;
>   	unsigned int nr_pages = 0;
>   
>   	if (!stock) {
> @@ -3327,7 +3328,18 @@ static void __refill_obj_stock(struct obj_cgroup *objcg,
>   		goto out;
>   	}
>   
> -	if (READ_ONCE(stock->cached_objcg) != objcg) { /* reset if necessary */
> +	cached = READ_ONCE(stock->cached_objcg);
> +	if (cached != objcg &&
> +	    (!cached || obj_cgroup_memcg(cached) != obj_cgroup_memcg(objcg))) {
>   		drain_obj_stock(stock);
>   		obj_cgroup_get(objcg);
>   		stock->nr_bytes = atomic_read(&objcg->nr_charged_bytes)

This change looks like it should be able to fix the ping-pong issue, but
I stiil haven't reproduced the performance regression locally. I'll
continue testing it.

Hi kernel-test-robot, could you help check if the patch above fixes the
issue on your end?

Thanks,
Qi