From nobody Fri Sep 25 23:50:54 2026 Received: from out30-113.freemail.mail.aliyun.com (out30-113.freemail.mail.aliyun.com [115.124.30.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 46F7A46C4A0; Mon, 7 Sep 2026 11:01:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.113 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788778883; cv=none; b=lS2UX1ziiFJLfI2C4IinWSIn0msZrZ3EjfCPG9DqS5BxzfLMKPRO7LV8fTpjq9T6L9l8HB3dlZmPXYxrcc+TFOisRW82buPop46q0TrzseQuqjn/bcZzMa0lmQYTJvBEadJGwZcQURgMkdYI8xhu1ovDAa6/aRN2oyHHptANCdg= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788778883; c=relaxed/simple; bh=JmB6QM6CMrbt+mYCdTNjZXLTnGlGEZ4aEm21cS2vffY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=oMd+o0nT60EuFFImYkBK8BwDq6XSYXOdQaKosI2IKbJp77DSUCWZtlKglsb+PmdG4+fNDj3HswL9+45+jh47oPBQswkllC9eU0/H6WcCa1AzPpJFqBIbqDrz14V4IFVhSXOIe4dcsQUJ7piidHzAPGHlxvjWNMuveUZAUQp47Ps= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=qvXe6E+/; arc=none smtp.client-ip=115.124.30.113 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="qvXe6E+/" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1788778878; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=eIX+mgn/05GG1BdcM7+jXBv8ObcWey0aeeYAiAqGu6I=; b=qvXe6E+/V6Js0sjV4y53xggnryH5udaH77/eg76gnYO/1gLcBKzSExp/4ABDHtbO6t2ozPImSE1vKGVF0j3AoTtjvBe/3+xOo/ykbfFABrLeOPla1KmHXsSmb2KOuZVqXL5e8g66JwmIEAgob91ubhrQBM1404TVMxFCBrf9fFo= X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R381e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037009110;MF=qinyuntan@linux.alibaba.com;NM=1;PH=DS;RN=21;SR=0;TI=SMTPD_---0XATsvzn_1788778875; Received: from banye.tbsite.net(mailfrom:qinyuntan@linux.alibaba.com fp:SMTPD_---0XATsvzn_1788778875 cluster:ay36) by smtp.aliyun-inc.com; Mon, 07 Sep 2026 19:01:16 +0800 From: Qinyun Tan To: Andrew Morton Cc: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , =?UTF-8?q?Michal=20Koutn=C3=BD?= , David Hildenbrand , Zi Yan , Baolin Wang , Usama Arif , Dave Chinner , Qi Zheng , Yosry Ahmed , Nhat Pham , Chengming Zhou , Xunlei Pang , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Qinyun Tan Subject: [PATCH v2 1/4] mm: memcontrol: drop kmemcg_id and use the memcg ID for list_lru indexing Date: Mon, 7 Sep 2026 19:01:08 +0800 Message-ID: <20260907110111.2286932-2-qinyuntan@linux.alibaba.com> X-Mailer: git-send-email 2.43.7 In-Reply-To: <20260907110111.2286932-1-qinyuntan@linux.alibaba.com> References: <20260907110111.2286932-1-qinyuntan@linux.alibaba.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" kmemcg_id is a copy of the memcg ID assigned in memcg_online_kmem(), and is only used as the list_lru xarray index. With cgroup.memory=3Dnokmem the assignment never happens, so every memcg resolves to the per-node lists. The next patch needs the index to work under nokmem as well, so drop the copy and use the memcg ID. The ID works just as well as the copy did: root and NULL still return -1 and use the per-node lists, and the ID is only released after the list_lru reparenting, so a stale or recycled ID can never reach a live list_lru entry. The early return of memcg_offline_kmem() under nokmem is dropped as well, so the reparenting also covers lrus that stay memcg aware without kmem accounting. Signed-off-by: Qinyun Tan --- include/linux/memcontrol.h | 8 +++++--- mm/list_lru.c | 10 +++++----- mm/memcontrol.c | 6 ------ 3 files changed, 10 insertions(+), 14 deletions(-) diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h index fdf4812e1d818..edeb287978934 100644 --- a/include/linux/memcontrol.h +++ b/include/linux/memcontrol.h @@ -254,7 +254,6 @@ struct mem_cgroup { #if BITS_PER_LONG < 64 seqlock_t socket_pressure_seqlock; #endif - int kmemcg_id; =20 #ifdef CONFIG_CGROUP_WRITEBACK struct list_head cgwb_list; @@ -1775,12 +1774,15 @@ static inline void memcg_kmem_uncharge_page(struct = page *page, int order) } =20 /* - * A helper for accessing memcg's kmem_id, used for getting + * A helper for accessing the memcg ID, used for getting * corresponding LRU lists. */ static inline int memcg_kmem_id(struct mem_cgroup *memcg) { - return memcg ? memcg->kmemcg_id : -1; + if (!memcg || mem_cgroup_is_root(memcg)) + return -1; + + return memcg->id.id; } =20 struct mem_cgroup *mem_cgroup_from_virt(void *p); diff --git a/mm/list_lru.c b/mm/list_lru.c index a4522ca93ebcb..6fd4e9af84396 100644 --- a/mm/list_lru.c +++ b/mm/list_lru.c @@ -502,7 +502,7 @@ static void memcg_reparent_list_lru_one(struct list_lru= *lru, int nid, struct list_lru_one *src, struct mem_cgroup *dst_memcg) { - int dst_idx =3D dst_memcg->kmemcg_id; + int dst_idx =3D memcg_kmem_id(dst_memcg); struct list_lru_one *dst; =20 spin_lock_irq(&src->lock); @@ -536,7 +536,7 @@ void memcg_reparent_list_lrus(struct mem_cgroup *memcg,= struct mem_cgroup *paren * allocating a new mlru since CSS_DYING is already set for this * memcg a rcu grace period ago. */ - mlru =3D xa_load(&lru->xa, memcg->kmemcg_id); + mlru =3D xa_load(&lru->xa, memcg_kmem_id(memcg)); if (!mlru) continue; =20 @@ -551,7 +551,7 @@ void memcg_reparent_list_lrus(struct mem_cgroup *memcg,= struct mem_cgroup *paren for_each_node(i) memcg_reparent_list_lru_one(lru, i, &mlru->node[i], parent); =20 - xa_erase_irq(&lru->xa, memcg->kmemcg_id); + xa_erase_irq(&lru->xa, memcg_kmem_id(memcg)); =20 /* * Here all list_lrus corresponding to the cgroup are guaranteed @@ -566,7 +566,7 @@ void memcg_reparent_list_lrus(struct mem_cgroup *memcg,= struct mem_cgroup *paren static inline bool memcg_list_lru_allocated(struct mem_cgroup *memcg, struct list_lru *lru) { - int idx =3D memcg->kmemcg_id; + int idx =3D memcg_kmem_id(memcg); =20 return idx < 0 || xa_load(&lru->xa, idx); } @@ -602,7 +602,7 @@ static int __memcg_list_lru_alloc(struct mem_cgroup *me= mcg, if (!mlru) return -ENOMEM; } - xas_set(&xas, pos->kmemcg_id); + xas_set(&xas, memcg_kmem_id(pos)); do { xas_lock_irqsave(&xas, flags); if (!xas_load(&xas) && !css_is_dying(&pos->css)) { diff --git a/mm/memcontrol.c b/mm/memcontrol.c index 7ce50bccf1264..619d4c1f2e8f2 100644 --- a/mm/memcontrol.c +++ b/mm/memcontrol.c @@ -3780,17 +3780,12 @@ static void memcg_online_kmem(struct mem_cgroup *me= mcg) return; =20 static_branch_enable(&memcg_kmem_online_key); - - memcg->kmemcg_id =3D memcg->id.id; } =20 static void memcg_offline_kmem(struct mem_cgroup *memcg) { struct mem_cgroup *parent; =20 - if (mem_cgroup_kmem_disabled()) - return; - if (unlikely(mem_cgroup_is_root(memcg))) return; =20 @@ -4225,7 +4220,6 @@ static struct mem_cgroup *mem_cgroup_alloc(struct mem= _cgroup *parent) seqlock_init(&memcg->socket_pressure_seqlock); #endif memcg1_memcg_init(memcg); - memcg->kmemcg_id =3D -1; #ifdef CONFIG_CGROUP_WRITEBACK INIT_LIST_HEAD(&memcg->cgwb_list); for (i =3D 0; i < MEMCG_CGWB_FRN_CNT; i++) --=20 2.43.7 From nobody Fri Sep 25 23:50:54 2026 Received: from out30-132.freemail.mail.aliyun.com (out30-132.freemail.mail.aliyun.com [115.124.30.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 533FD47668B; Mon, 7 Sep 2026 11:01:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.132 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788778885; cv=none; b=m46DdYKz/VNyMhHzr4OXQYh5PfrAimUiCZ8mEZWXwwe5saAxZcDxYOP80/qjB06u/sbXgXGwmi33GSkdZeJwLMRg48FqYt8QhVp0yIR3vNHsKq8bNfZEcWYrF9HvAI9UtDs3N4v5nIYo572QOC34u1HfQsKIo4jiKBT8tKToBlo= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788778885; c=relaxed/simple; bh=VCcBOevO7v28DR9ElX4VKsm9629srGlmO6ARvLKxABY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=AAVZuMtmok09RQIQ2CO39y5g6pv7De9uv2/+yJ7G9LeXYe+lb7uqGT6zJJZCML0FNYLMbaFlkkvtl84l0hzRJJjAzZ5AsfYGI/H+9fxCTkDJ0YdGMed/Y7PyP1p6nx92aGdw+LvXXtIOawnzZWKgpYwFEqLmIleRe6bm/wfetuM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=B78lB6sL; arc=none smtp.client-ip=115.124.30.132 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="B78lB6sL" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1788778879; h=From:To:Subject:Date:Message-ID:MIME-Version; bh=wwR9RFSxdLQeFFx4l5snm8ZYfxhsC29aBhmlxjFMRxc=; b=B78lB6sLNzoq4YrESjvHeWhAidY6vhXDEDiGBpAG9bUZ7QyZk7fP9WOdaP+b1UvEiDmywiBCl890De1b1KvaAat0FLlr9kGq4FCXidMbI00xztWLaSEbWTpK7VCxf/cDqfsjhE8lNGRLkha6P7kCuIEMjbTm1YyiillVrLHDaQc= X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R471e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam011083073210;MF=qinyuntan@linux.alibaba.com;NM=1;PH=DS;RN=21;SR=0;TI=SMTPD_---0XATsw-l_1788778876; Received: from banye.tbsite.net(mailfrom:qinyuntan@linux.alibaba.com fp:SMTPD_---0XATsw-l_1788778876 cluster:ay36) by smtp.aliyun-inc.com; Mon, 07 Sep 2026 19:01:17 +0800 From: Qinyun Tan To: Andrew Morton Cc: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , =?UTF-8?q?Michal=20Koutn=C3=BD?= , David Hildenbrand , Zi Yan , Baolin Wang , Usama Arif , Dave Chinner , Qi Zheng , Yosry Ahmed , Nhat Pham , Chengming Zhou , Xunlei Pang , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Qinyun Tan Subject: [PATCH v2 2/4] mm: list_lru: keep per-memcg lists with nokmem for NONSLAB-backed lrus Date: Mon, 7 Sep 2026 19:01:09 +0800 Message-ID: <20260907110111.2286932-3-qinyuntan@linux.alibaba.com> X-Mailer: git-send-email 2.43.7 In-Reply-To: <20260907110111.2286932-1-qinyuntan@linux.alibaba.com> References: <20260907110111.2286932-1-qinyuntan@linux.alibaba.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" With cgroup.memory=3Dnokmem, __list_lru_init() collapses every list_lru into per-node lists. That is fine for slab objects, which are not charged per memcg without kmem accounting. But a lru backed by a SHRINKER_NONSLAB shrinker, e.g. the THP deferred split queue or the zswap entries, holds user memory, which is charged regardless of nokmem. Collapsing such an lru loses the per-memcg view of its objects. Reclaim can no longer target just the cgroup under pressure. Keep such lrus memcg aware under nokmem when their backing shrinker is registered SHRINKER_NONSLAB. This leaves the savings of nokmem intact: slab-backed lrus (e.g. the superblock dentry/inode lrus) still fall back to the per-node lists, and the per-memcg lists are allocated only when a memcg actually holds such objects. Fixes: fafaeceb89a5 ("mm: switch deferred split shrinker to list_lru") Signed-off-by: Qinyun Tan Reviewed-by: Johannes Weiner --- mm/list_lru.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/mm/list_lru.c b/mm/list_lru.c index 6fd4e9af84396..e84eff313a683 100644 --- a/mm/list_lru.c +++ b/mm/list_lru.c @@ -671,7 +671,9 @@ int __list_lru_init(struct list_lru *lru, bool memcg_aw= are, struct shrinker *shr else lru->shrinker_id =3D -1; =20 - if (mem_cgroup_disabled() || mem_cgroup_kmem_disabled()) + if (mem_cgroup_disabled() || + (mem_cgroup_kmem_disabled() && + (!shrinker || !(shrinker->flags & SHRINKER_NONSLAB)))) memcg_aware =3D false; #endif =20 --=20 2.43.7 From nobody Fri Sep 25 23:50:54 2026 Received: from out30-101.freemail.mail.aliyun.com (out30-101.freemail.mail.aliyun.com [115.124.30.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 50D9448CD40; Mon, 7 Sep 2026 11:01:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.101 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788778885; cv=none; b=fNrlduTDS+Rn8tl0g+/3BrqpBJLfnUJEOcyZE20GNXJyia/wybw1Th9IPW+BCBeiCPtUpVy9EfeaEhOu53jnYfEl7sNiA9nCB5fMwfFJNCH3Jo/j+vFQJ17n1Yn1G05OAO0wjj7fh9Hi8AqRhmG7la5Yuw0fa321iZRKSUF0BzU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788778885; c=relaxed/simple; bh=6ec5OpU3JoMvKMwc66OsCsaRbuZsMKGll5y1quzBcog=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=FUPjd8jAfQWBocZ19N+BfVoU0FVOOQMM6khyzWdulEDiS5GVcv+cq73rrYZ81rOk78DFDwM5Ke41DbuWOJRdnUNTFNu03lK2QahUU9TihYxVPLgkRNGmWRXY5nZAPtAzB8fq12hLuuq6uTZ28MAGJVq7LLAM2aRzonogOEA+idE= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=ufLa2YZ7; arc=none smtp.client-ip=115.124.30.101 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="ufLa2YZ7" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1788778881; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=cmWYNJGIXxazgZ5q5HpJHBhK6Ac8N304N8jTgUaL0cU=; b=ufLa2YZ7Va6TgXA4VKxj1Yvnk9V0zZmF0Wrtd4Ysr9qH5kWh1VCWS50KEjw1Vlv4sWzV43y4/gcOH0Jqfn+HjAiwLGSHVW0s0NxcT+quvL66X4p9sclfJYvu27/+OuhJDncxVrohPqKgzTjwkwUMf7OzWghIutEyHJC12ZbflD8= X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R101e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037026112;MF=qinyuntan@linux.alibaba.com;NM=1;PH=DS;RN=21;SR=0;TI=SMTPD_---0XATsw.3_1788778878; Received: from banye.tbsite.net(mailfrom:qinyuntan@linux.alibaba.com fp:SMTPD_---0XATsw.3_1788778878 cluster:ay36) by smtp.aliyun-inc.com; Mon, 07 Sep 2026 19:01:19 +0800 From: Qinyun Tan To: Andrew Morton Cc: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , =?UTF-8?q?Michal=20Koutn=C3=BD?= , David Hildenbrand , Zi Yan , Baolin Wang , Usama Arif , Dave Chinner , Qi Zheng , Yosry Ahmed , Nhat Pham , Chengming Zhou , Xunlei Pang , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Qinyun Tan Subject: [PATCH v2 3/4] mm: thp: restore SHRINKER_NONSLAB on the deferred split shrinker Date: Mon, 7 Sep 2026 19:01:10 +0800 Message-ID: <20260907110111.2286932-4-qinyuntan@linux.alibaba.com> X-Mailer: git-send-email 2.43.7 In-Reply-To: <20260907110111.2286932-1-qinyuntan@linux.alibaba.com> References: <20260907110111.2286932-1-qinyuntan@linux.alibaba.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On a system booted with cgroup.memory=3Dnokmem, the deferred split shrinker is quietly demoted to a non-memcg-aware one. As a result, partially unmapped THPs are only split under global reclaim; memcg (limit-induced) reclaim never splits them, so a cgroup under memory pressure keeps its underused THPs intact. This is a regression from commit fafaeceb89a5 ("mm: switch deferred split shrinker to list_lru"), which re-registered the shrinker without SHRINKER_NONSLAB. The shrinker had carried this flag since commit 0a432dcbeb32 ("mm: shrinker: make shrinker not depend on memcg kmem") precisely so it would keep working with kmem accounting disabled. Without the flag, shrinker_memcg_alloc() fails with -ENOSYS under nokmem and the shrinker loses its memcg awareness. This was noticed by Michal during review of the patch "mm/list_lru: don't copy stale shrinker id from non-memcg-aware shrinkers" [1]. Restore the flag. [1] https://lore.kernel.org/lkml/697713c4-0857-485b-aba7-c74f37a3c8b4@linux= .alibaba.com/ Fixes: fafaeceb89a5 ("mm: switch deferred split shrinker to list_lru") Suggested-by: Michal Koutn=C3=BD Signed-off-by: Qinyun Tan Acked-by: Zi Yan Acked-by: David Hildenbrand (Arm) Acked-by: Usama Arif Reviewed-by: Baolin Wang Reviewed-by: Johannes Weiner --- mm/huge_memory.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/mm/huge_memory.c b/mm/huge_memory.c index c5d11147b69ae..87c9fc48b7cfd 100644 --- a/mm/huge_memory.c +++ b/mm/huge_memory.c @@ -1064,7 +1064,8 @@ int folio_memcg_alloc_deferred(struct folio *folio) static int __init thp_shrinker_init(void) { deferred_split_shrinker =3D shrinker_alloc(SHRINKER_NUMA_AWARE | - SHRINKER_MEMCG_AWARE, + SHRINKER_MEMCG_AWARE | + SHRINKER_NONSLAB, "thp-deferred_split"); if (!deferred_split_shrinker) return -ENOMEM; --=20 2.43.7 From nobody Fri Sep 25 23:50:54 2026 Received: from out30-111.freemail.mail.aliyun.com (out30-111.freemail.mail.aliyun.com [115.124.30.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E72D748F856; Mon, 7 Sep 2026 11:01:25 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.30.111 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788778887; cv=none; b=C2TwOFm6UG5jdBYT5UsCjzaNZp4PximbXZRp2l/W4d2b5HVfXREdnPVIrpK8wgX0Z4vC/uxIfdYFbRKPCnDXMgfIDSOJgyYJScYY6Onvogdv0ogFs1xtNeQ2hpSVISPTvGGPm7RkOfawml73SVfZyQJKMaMWqy0NNQ5x8oTxD8U= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1788778887; c=relaxed/simple; bh=7Ftp8y+FQkkUlSbiO8cVb1oujNocCQyqrrp+m8m8p84=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version:Content-Type; b=ThgCMNF197Yl3FgkJhEJEn8hTRVXAkTeP4OkJnckGPKvkl5Xqfp3hF09dQqcFsNCeFB3eZMJYr+d33HEgK4KMXQYl3FmhIiCvNxjxUZmnxReTdkhzUh+nYKdcAueaH5LqYJobkGrh9SryLycu+E0ZinTtqSGzfPIg/zzOfwfCFw= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com; spf=pass smtp.mailfrom=linux.alibaba.com; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b=Fo21JJN1; arc=none smtp.client-ip=115.124.30.111 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.alibaba.com header.i=@linux.alibaba.com header.b="Fo21JJN1" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.alibaba.com; s=default; t=1788778883; h=From:To:Subject:Date:Message-ID:MIME-Version:Content-Type; bh=/kTenwfhjwRZAsn2gE4kzIQoYtAxda9Qf9Jtbo1G+2k=; b=Fo21JJN17jWlrMqcmdmCYtrKIRurtFzI0FT3CbAtJ2JHEXQ6EGidRer/mbCwdbJvhkIzcZP1PfywKlao0ToevI4uTHJpWP1Y1Tyc5xiQSxU9uLGqcIQbYigYE5zcSEDaVUXx2JSYO//xbIdJ1gnXuiF4jWVud+frgqx73pVgCsI= X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R161e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=maildocker-contentspam033037026112;MF=qinyuntan@linux.alibaba.com;NM=1;PH=DS;RN=21;SR=0;TI=SMTPD_---0XATsw.a_1788778880; Received: from banye.tbsite.net(mailfrom:qinyuntan@linux.alibaba.com fp:SMTPD_---0XATsw.a_1788778880 cluster:ay36) by smtp.aliyun-inc.com; Mon, 07 Sep 2026 19:01:21 +0800 From: Qinyun Tan To: Andrew Morton Cc: Johannes Weiner , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , =?UTF-8?q?Michal=20Koutn=C3=BD?= , David Hildenbrand , Zi Yan , Baolin Wang , Usama Arif , Dave Chinner , Qi Zheng , Yosry Ahmed , Nhat Pham , Chengming Zhou , Xunlei Pang , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Qinyun Tan Subject: [PATCH v2 4/4] mm: zswap: mark the zswap shrinker SHRINKER_NONSLAB Date: Mon, 7 Sep 2026 19:01:11 +0800 Message-ID: <20260907110111.2286932-5-qinyuntan@linux.alibaba.com> X-Mailer: git-send-email 2.43.7 In-Reply-To: <20260907110111.2286932-1-qinyuntan@linux.alibaba.com> References: <20260907110111.2286932-1-qinyuntan@linux.alibaba.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable With kmem accounting disabled (cgroup.memory=3Dnokmem), memcg reclaim never invokes the zswap shrinker: a cgroup under memory pressure does not write back its own zswapped pages to make room; they are only written back by global reclaim or once the global pool limit kicks in. The zswap shrinker is registered memcg-aware but without SHRINKER_NONSLAB, so under nokmem it is treated as a slab shrinker: before commit 03375203e1da ("mm: do not allocate shrinker info with cgroup.memory=3Dnokmem") it was skipped by the !memcg_kmem_online() check in shrink_slab_memcg(); since that commit it is demoted to non-memcg-aware at registration. But the zswap shrinker is not a slab shrinker: it tracks zswap entries and resolves the owning memcg from the folio's objcg, independent of kmem accounting. This was noticed by Michal during review of the patch "mm/list_lru: don't copy stale shrinker id from non-memcg-aware shrinkers" [1]. Mark it SHRINKER_NONSLAB so it keeps its memcg awareness and runs under memcg reclaim with nokmem. [1] https://lore.kernel.org/lkml/697713c4-0857-485b-aba7-c74f37a3c8b4@linux= .alibaba.com/ Fixes: b5ba474f3f51 ("zswap: shrink zswap pool based on memory pressure") Suggested-by: Michal Koutn=C3=BD Signed-off-by: Qinyun Tan Acked-by: Usama Arif Acked-by: Yosry Ahmed Reviewed-by: Johannes Weiner --- mm/zswap.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/mm/zswap.c b/mm/zswap.c index f3ae3c81e48ea..032136942c172 100644 --- a/mm/zswap.c +++ b/mm/zswap.c @@ -1252,8 +1252,8 @@ static struct shrinker *zswap_alloc_shrinker(void) { struct shrinker *shrinker; =20 - shrinker =3D - shrinker_alloc(SHRINKER_NUMA_AWARE | SHRINKER_MEMCG_AWARE, "mm-zswap"); + shrinker =3D shrinker_alloc(SHRINKER_NUMA_AWARE | SHRINKER_MEMCG_AWARE | + SHRINKER_NONSLAB, "mm-zswap"); if (!shrinker) return NULL; =20 --=20 2.43.7