From: Harry Yoo <harry.yoo@oracle.com>
To: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
Cc: Ming Lei <ming.lei@redhat.com>, Hao Li <hao.li@linux.dev>,
Andrew Morton <akpm@linux-foundation.org>,
Christoph Lameter <cl@gentwo.org>,
David Rientjes <rientjes@google.com>,
Roman Gushchin <roman.gushchin@linux.dev>,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/3] slab: decouple pointer to barn from kmem_cache_node
Date: Fri, 13 Mar 2026 18:27:06 +0900 [thread overview]
Message-ID: <abPYaocgFylosUCf@hyeyoo> (raw)
In-Reply-To: <20260311-b4-slab-memoryless-barns-v1-1-70ab850be4ce@kernel.org>
On Wed, Mar 11, 2026 at 09:25:55AM +0100, Vlastimil Babka (SUSE) wrote:
> The pointer to barn currently exists in struct kmem_cache_node. That
> struct is instantiated for every NUMA node with memory, but we want to
> have a barn for every online node (including memoryless).
>
> Thus decouple the two structures. In struct kmem_cache we have an array
> for kmem_cache_node pointers that appears to be sized MAX_NUMNODES but
> the actual size calculation in kmem_cache_init() uses nr_node_ids.
> Therefore we can't just add another array of barn pointers. Instead
> change the array to newly introduced struct kmem_cache_per_node_ptrs
> holding both kmem_cache_node and barn pointer.
>
> Adjust barn accessor and allocation/initialization code accordingly. For
> now no functional change intended, barns are created 1:1 together with
> kmem_cache_nodes.
>
> Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
> ---
> mm/slab.h | 7 +++-
> mm/slub.c | 128 +++++++++++++++++++++++++++++++++++---------------------------
> 2 files changed, 78 insertions(+), 57 deletions(-)
>
> diff --git a/mm/slab.h b/mm/slab.h
> index e9ab292acd22..c735e6b4dddb 100644
> --- a/mm/slab.h
> +++ b/mm/slab.h
> @@ -247,7 +252,7 @@ struct kmem_cache {
> struct kmem_cache_stats __percpu *cpu_stats;
> #endif
>
> - struct kmem_cache_node *node[MAX_NUMNODES];
> + struct kmem_cache_per_node_ptrs per_node[MAX_NUMNODES];
> };
We should probably turn this into a true flexible array at some point,
but that's out of scope for this patchset.
> diff --git a/mm/slub.c b/mm/slub.c
> index 20cb4f3b636d..609a183f8533 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -436,26 +436,24 @@ struct kmem_cache_node {
> /*
> - * Get the barn of the current cpu's closest memory node. It may not exist on
> - * systems with memoryless nodes but without CONFIG_HAVE_MEMORYLESS_NODES
> + * Get the barn of the current cpu's memory node. It may be a memoryless node.
> */
> static inline struct node_barn *get_barn(struct kmem_cache *s)
> {
> - struct kmem_cache_node *n = get_node(s, numa_mem_id());
> -
> - if (!n)
> - return NULL;
> -
> - return n->barn;
> + return get_barn_node(s, numa_node_id());
> }
Previously, memoryless nodes on architectures w/ CONFIG_HAVE_MEMORYLESS_NODES
shared the barn of the nearest NUMA node with memory.
But now memoryless nodes will have their own barns (after patch 2)
regardless of CONFIG_HAVE_MEMORYLESS_NODES, and that's intentional, right?
Otherwise LGTM!
--
Cheers,
Harry / Hyeonggon
next prev parent reply other threads:[~2026-03-13 9:27 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-11 8:25 [PATCH 0/3] slab: support memoryless nodes with sheaves Vlastimil Babka (SUSE)
2026-03-11 8:25 ` [PATCH 1/3] slab: decouple pointer to barn from kmem_cache_node Vlastimil Babka (SUSE)
2026-03-13 9:27 ` Harry Yoo [this message]
2026-03-13 9:46 ` Vlastimil Babka (SUSE)
2026-03-13 11:48 ` Harry Yoo
2026-03-16 13:19 ` Vlastimil Babka (SUSE)
2026-04-10 10:12 ` Christoph Lameter (Ampere)
2026-04-13 12:07 ` Vlastimil Babka (SUSE)
2026-03-11 8:25 ` [PATCH 2/3] slab: create barns for online memoryless nodes Vlastimil Babka (SUSE)
2026-03-16 3:25 ` Harry Yoo
2026-03-18 9:27 ` Hao Li
2026-03-18 12:11 ` Vlastimil Babka (SUSE)
2026-03-19 7:01 ` Hao Li
2026-03-19 9:56 ` Vlastimil Babka (SUSE)
2026-03-19 11:27 ` Hao Li
2026-03-19 12:25 ` Vlastimil Babka (SUSE)
2026-03-11 8:25 ` [PATCH 3/3] slab: free remote objects to sheaves on " Vlastimil Babka (SUSE)
2026-03-16 3:48 ` Harry Yoo
2026-03-11 9:49 ` [PATCH 0/3] slab: support memoryless nodes with sheaves Ming Lei
2026-03-11 17:22 ` Vlastimil Babka (SUSE)
2026-04-08 13:04 ` Jon Hunter
2026-04-08 14:06 ` Hao Li
2026-04-09 20:02 ` Jon Hunter
2026-04-08 14:31 ` Harry Yoo (Oracle)
2026-04-09 20:11 ` Jon Hunter
2026-04-13 12:11 ` Vlastimil Babka (SUSE)
2026-03-16 13:33 ` Vlastimil Babka (SUSE)
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=abPYaocgFylosUCf@hyeyoo \
--to=harry.yoo@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=cl@gentwo.org \
--cc=hao.li@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ming.lei@redhat.com \
--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.