From: Harry Yoo <harry@kernel.org>
To: Hao Li <hao.li@linux.dev>, vbabka@kernel.org, akpm@linux-foundation.org
Cc: cl@gentwo.org, rientjes@google.com, roman.gushchin@linux.dev,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] mm/slub: allocate sheaves on local memory nodes
Date: Mon, 1 Jun 2026 20:28:16 +0900 [thread overview]
Message-ID: <33506b25-ab2f-4f31-a380-7c0fe65567a3@kernel.org> (raw)
In-Reply-To: <20260601095706.106551-1-hao.li@linux.dev>
[-- Attachment #1.1: Type: text/plain, Size: 1888 bytes --]
On 6/1/26 6:56 PM, Hao Li wrote:
> Sheaf structs are exchanged through node-local barns. Since barn structs
> are already allocated from their local NUMA node, this patch aims to
> allocate sheaf structs from their local memory nodes as well.
>
> To achieve this, the obvious choice would be using cpu_to_mem().
> However, init_percpu_sheaves() and bootstrap_cache_sheaves() iterate
> through possible CPUs, whereas cpu_to_mem() is only initialized for
> online CPUs. Therefore, we cannot use cpu_to_mem() and instead need to
> use local_memory_node(cpu_to_node(cpu)), similar to what
> __build_all_zonelists() does.
>
> The primary goal of this patch is to improve NUMA node locality.
> Although the actual performance impact is minor, it still yields a ~1%
> improvement on a 192-core, 8-NUMA-node system when testing with the
> will-it-scale mmap test case.
Oh, nice :)
I have a question though...
I wonder if would be better to handle this by e.g.) not returning empty
sheaves back to barn and freeing them if the node id doesn't match and
it's not a memoryless node.
init_percpu_sheaves() and bootstrap_cache_sheaves() are not the only
places that can allocate sheaves from remote nodes; sheaves allocation
could fall back to other nodes and then SLUB could keep reusing those
sheaves from remote nodes even after memory is reclaimed.
If this works well, we probably don't need to handle it in
init_percpu_sheaves() and bootstrap_cache_sheaves() at all as they will
eventually be freed, while covering the other case too?
> Signed-off-by: Hao Li <hao.li@linux.dev>
> ---
> Changes in v2:
> - Make init_percpu_sheaves() use a NUMA-aware sheaf struct allocation too.
> (Thanks Harry)
> - Rebase on latest code.
>
> v1: https://lore.kernel.org/linux-mm/20260525082312.16012-1-hao.li@linux.dev/
--
Cheers,
Harry / Hyeonggon
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
next prev parent reply other threads:[~2026-06-01 11:28 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-01 9:56 Hao Li
2026-06-01 11:28 ` Harry Yoo [this message]
2026-06-03 4:26 ` Hao Li
2026-06-09 3:41 ` Harry Yoo
2026-06-09 10:14 ` Vlastimil Babka (SUSE)
2026-06-10 1:49 ` Harry Yoo
2026-06-10 2:51 ` Hao Li
2026-06-10 2:47 ` Hao Li
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=33506b25-ab2f-4f31-a380-7c0fe65567a3@kernel.org \
--to=harry@kernel.org \
--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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®