From: Hao Li <hao.li@linux.dev>
To: vbabka@kernel.org, harry.yoo@oracle.com, akpm@linux-foundation.org
Cc: cl@gentwo.org, rientjes@google.com, roman.gushchin@linux.dev,
linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Hao Li <hao.li@linux.dev>
Subject: [PATCH] slub: use N_NORMAL_MEMORY in can_free_to_pcs to handle remote frees
Date: Fri, 3 Apr 2026 15:37:36 +0800 [thread overview]
Message-ID: <20260403073958.8722-1-hao.li@linux.dev> (raw)
Memory hotplug now keeps N_NORMAL_MEMORY up to date correctly, so make
can_free_to_pcs() use it.
As a result, when freeing objects on memoryless nodes, or on nodes that
have memory but only in ZONE_MOVABLE, the objects can be freed to the
sheaf instead of going through the slow path.
Signed-off-by: Hao Li <hao.li@linux.dev>
---
Hi Vlastimil, this patch depends on a prerequisite patch[1] from a few days
ago. I'm not sure how this should be handled. I wonder if Andrew might put them
in the same tree.
[1] https://lore.kernel.org/linux-mm/20260330035941.518186-1-hao.li@linux.dev/
---
mm/slub.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/mm/slub.c b/mm/slub.c
index fb2c5c57bc4e..4927407c9699 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -6022,14 +6022,15 @@ static __always_inline bool can_free_to_pcs(struct slab *slab)
goto check_pfmemalloc;
/*
- * Freed object isn't from this cpu's node, but that node is memoryless.
+ * Freed object isn't from this cpu's node, but that node is memoryless
+ * or only has ZONE_MOVABLE memory, which slab cannot allocate from.
* Proceed as it's better to cache remote objects than falling back to
* the slowpath for everything. The allocation side can never obtain
* a local object anyway, if none exist. We don't have numa_mem_id() to
* point to the closest node as we would on a proper memoryless node
* setup.
*/
- if (unlikely(!node_state(numa_node, N_MEMORY)))
+ if (unlikely(!node_state(numa_node, N_NORMAL_MEMORY)))
goto check_pfmemalloc;
#endif
--
2.50.1
next reply other threads:[~2026-04-03 7:40 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-03 7:37 Hao Li [this message]
2026-04-03 12:02 ` [PATCH] slub: use N_NORMAL_MEMORY in can_free_to_pcs to handle remote frees Harry Yoo (Oracle)
2026-04-03 18:14 ` Vlastimil Babka (SUSE)
2026-04-04 4:05 ` Hao Li
2026-04-06 1:57 ` Harry Yoo (Oracle)
2026-04-03 18:02 ` David Rientjes
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260403073958.8722-1-hao.li@linux.dev \
--to=hao.li@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=cl@gentwo.org \
--cc=harry.yoo@oracle.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=vbabka@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.