Re: [PATCH] mm/slub: deduplicate NUMA policy calculation in allocation paths

[Harry Yoo <harry@kernel.org>]

[-- Attachment #1.1: Type: text/plain, Size: 1509 bytes --]



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@linux.dev>
> ---
>  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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]