linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
To: "Christoph Lameter (Ampere)" <cl@gentwo.org>
Cc: Ming Lei <ming.lei@redhat.com>, Harry Yoo <harry.yoo@oracle.com>,
	Hao Li <hao.li@linux.dev>,
	Andrew Morton <akpm@linux-foundation.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: Mon, 13 Apr 2026 14:07:59 +0200	[thread overview]
Message-ID: <80db81dc-99a5-487c-99d8-3ff5a687714a@kernel.org> (raw)
In-Reply-To: <f29c0348-0250-b34b-59df-9dd59e4985ee@gentwo.org>

On 4/10/26 12:12, Christoph Lameter (Ampere) wrote:
> On Wed, 11 Mar 2026, 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).
> 
> Is this breaking the 1-1 association of kmem_cache to numa
> nodes?

Assuming you mean association of kmem_cache_node to NUMA non-memoryless nodes?

Indeed if we didn't separate pointer to barn from kmem_cache_node and
started instantiating kmem_cache_node on memoryless NUMA nodes, it would
break this 1-1 association. But with the separation, it shouldn't.

> I would think you needd local per cpu queues on a memoryless node
> for performance but not fake node structures.

"barn" is only for handling per cpu queues (sheaves), not the other per-node
structures. On memoryless node the sheaves will hold remote objects (as
there are no local objects) so it's fine that there's also barn for sheaves
with remote objects (and empty sheaves).

> Per node access is already
> serialized via locks and therefore slow.
> 
> If you break the association of per cpu queues to cpu and kmem_cache_node
> to numa_nodes then the code may get complicated.
The sheaves "empty on alloc"/"full on free" handling code would be more
complicated if the barns didn't exist for memoryless nodes, so it's better
if it does. The kmem_cache_node with partial (and other) slab lists keeps
not existing on memoryless nodes.


  reply	other threads:[~2026-04-13 12:08 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
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) [this message]
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=80db81dc-99a5-487c-99d8-3ff5a687714a@kernel.org \
    --to=vbabka@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=cl@gentwo.org \
    --cc=hao.li@linux.dev \
    --cc=harry.yoo@oracle.com \
    --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 \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox