Re: [PATCH v5 update 30/32] mm: memcontrol: convert objcg to be per-memcg per-node type

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

Hi Shakeel,

On 2/26/26 10:27 AM, Shakeel Butt wrote:
> On Wed, Feb 25, 2026 at 05:44:56PM +0800, Qi Zheng wrote:
>> From: Qi Zheng <zhengqi.arch@bytedance.com>
>>
>> Convert objcg to be per-memcg per-node type, so that when reparent LRU
>> folios later, we can hold the lru lock at the node level, thus avoiding
>> holding too many lru locks at once.
>>
>> Signed-off-by: Qi Zheng <zhengqi.arch@bytedance.com>
>> ---
>> changlog:
>>   - fix a missing root_obj_cgroup conversion and completely delete
>>     root_obj_cgroup.
>>
>>   include/linux/memcontrol.h | 23 +++++------
>>   include/linux/sched.h      |  2 +-
>>   mm/memcontrol.c            | 79 +++++++++++++++++++++++---------------
>>   3 files changed, 62 insertions(+), 42 deletions(-)
>>
>> diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
>> index 45d911dd903e7..6e11552a90618 100644
>> --- a/include/linux/memcontrol.h
>> +++ b/include/linux/memcontrol.h
>> @@ -116,6 +116,16 @@ struct mem_cgroup_per_node {
>>   	unsigned long		lru_zone_size[MAX_NR_ZONES][NR_LRU_LISTS];
>>   	struct mem_cgroup_reclaim_iter	iter;
>>   
>> +	/*
>> +	 * objcg is wiped out as a part of the objcg repaprenting process.
>> +	 * orig_objcg preserves a pointer (and a reference) to the original
>> +	 * objcg until the end of live of memcg.
>> +	 */
>> +	struct obj_cgroup __rcu	*objcg;
>> +	struct obj_cgroup	*orig_objcg;
> 
> The layout of struct mem_cgroup_per_node is very performance sensitive. Please
> couple of performance benchmarks after rearranging the fields particularly the

I ran a simple test using will-it-scale page_fault1, and the results are
as follows:

tasks    | baseline     | with-patch   | diff       | %
-------------------------------------------------------------
1        | 216394       | 217537       | +1143      | +0.53%
2        | 419895       | 421510       | +1615      | +0.38%
3        | 626275       | 629533       | +3258      | +0.52%
4        | 833146       | 830481       | -2665      | -0.32%
5        | 1037597      | 1034334      | -3263      | -0.31%
6        | 1229398      | 1231656      | +2258      | +0.18%
7        | 1425040      | 1424432      | -608       | -0.04%
8        | 1603738      | 1626028      | +22290     | +1.39%
9        | 1797881      | 1803901      | +6020      | +0.33%
10       | 1976264      | 1966342      | -9922      | -0.50%
11       | 2150073      | 2159328      | +9255      | +0.43%
12       | 2304435      | 2321128      | +16693     | +0.72%
13       | 2524668      | 2538582      | +13914     | +0.55%
14       | 2763854      | 2743098      | -20756     | -0.75%
15       | 2938939      | 2961671      | +22732     | +0.77%
16       | 3152497      | 3181420      | +28923     | +0.92%
17       | 3333936      | 3370667      | +36731     | +1.10%
18       | 3531225      | 3552907      | +21682     | +0.61%
19       | 3732347      | 3769889      | +37542     | +1.01%
20       | 3917502      | 3951226      | +33724     | +0.86%
21       | 4118040      | 4134952      | +16912     | +0.41%
22       | 4268932      | 4312343      | +43411     | +1.02%
23       | 4438411      | 4484408      | +45997     | +1.04%
24       | 4618400      | 4683531      | +65131     | +1.41%

No obvious degradation observed, so I'll keep this arrangement in v6.

> above two pointers together at the start of the struct.
> 
> Otherwise:
> 
> Acked-by: Shakeel Butt <shakeel.butt@linux.dev>

Thanks! I'll add this tag in v6.