From: Hao Li <hao.li@linux.dev>
To: Harry Yoo <harry@kernel.org>
Cc: vbabka@kernel.org, akpm@linux-foundation.org, cl@gentwo.org,
rientjes@google.com, roman.gushchin@linux.dev,
linux-mm@kvack.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] mm/slub: allocate sheaves on local memory nodes
Date: Tue, 26 May 2026 15:59:58 +0800 [thread overview]
Message-ID: <ahVRviGfYjPglJKB@fedora> (raw)
In-Reply-To: <15f22716-0065-4814-8be3-7730ff34cf34@kernel.org>
On Tue, May 26, 2026 at 03:56:58PM +0900, Harry Yoo wrote:
>
>
> On 5/25/26 5:13 PM, Hao Li wrote:
> > Sheaves are per-CPU allocator metadata and their object arrays are accessed
> > from the local fast paths. Allocate them with a NUMA node hint instead of
> > using plain kzalloc(). While no measurable performance improvement was
> > observed, this approach is theoretically correct.
> >
> > During bootstrap we allocate sheaves for all possible CPUs before every
> > possible CPU has an initialized cpu_to_mem() value, so compute the
> > memory node from local_memory_node(cpu_to_node(cpu)) just like
> > what __build_all_zonelists does.
>
>
> What about sheaves for non-kmalloc-normal caches that are allocated &
> initialized by init_percpu_sheaves()?
Ah, good catch! Thanks for the reminder! I completely overlooked this, which
unfortunately means most non-kmalloc caches have been missing out on the
benefits of this patch.
init_percpu_sheaves() also contain for_each_possible_cpu loops. It should also
retrieve the node id from the cpu idx, rather than relying on numa_mem_id()
inside alloc_empty_sheaf().
>
> Would addressing above change "no measurable performance impact was
> observed"?
It looks like we should get some performance gains now. (Hope so:))
--
Thanks,
Hao
prev parent reply other threads:[~2026-05-26 8:00 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-25 8:13 [PATCH] mm/slub: allocate sheaves on local memory nodes Hao Li
2026-05-26 6:56 ` Harry Yoo
2026-05-26 7:59 ` Hao Li [this message]
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=ahVRviGfYjPglJKB@fedora \
--to=hao.li@linux.dev \
--cc=akpm@linux-foundation.org \
--cc=cl@gentwo.org \
--cc=harry@kernel.org \
--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.