Re: [PATCH] mm/slub: deduplicate NUMA policy calculation in allocation paths
From: Harry Yoo
Date: Fri Jun 19 2026 - 01:50:52 EST
On 6/18/26 7:08 PM, Hao Li wrote:
> Currently, alloc_from_pcs() and __slab_alloc_node() both calculate the
> NUMA policy independently. Since they are called consecutively in paths
> like __kmalloc_nolock_noprof() and slab_alloc_node(), this leads to
> redundant computations.
It uses a static key, so probably just slightly larger code when disabled.
By inlining both __slab_alloc_node and alloc_from_pcs(), I assume the
compiler would have deduplicated it, but there is a patch in
slab/for-next that makes it not inlined anymore :)
> Introduce a helper function to resolve the NUMA policy once, eliminating
> the duplicated code and reducing execution overhead.
Nice! I think there's no reason why we shouldn't do this.
> Signed-off-by: Hao Li <hao.li@xxxxxxxxx>
> ---
> mm/slub.c | 72 ++++++++++++++++++++++---------------------------------
> 1 file changed, 29 insertions(+), 43 deletions(-)
>
> diff --git a/mm/slub.c b/mm/slub.c
> index 62e9cd46916f..45e9f379b7da 100644
> --- a/mm/slub.c
> +++ b/mm/slub.c
> @@ -4523,32 +4523,36 @@ static void *___slab_alloc(struct kmem_cache *s, gfp_t gfpflags, int node,
> return object;
> }
>
> +static __always_inline int apply_numa_policy(int node)
apply_numa_policy() is bit confusing because we usually don't apply
mempolicy for each object (unless strict_numa is set), but rather when
grabbing new slabs.
perhaps apply_strict_numa[_policy]() will be a better name?
--
Cheers,
Harry / Hyeonggon
Attachment:
OpenPGP_signature.asc
Description: OpenPGP digital signature