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

[Hao Li <hao.li@linux.dev>]

On Fri, Jun 19, 2026 at 02:50:04PM +0900, Harry Yoo wrote:
> 
> 
> 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.

Yeah, make sense. The performance impact in this case should be negligible.

> 
> 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 :)

Thanks, I hadn't thought about it from that angle before, and that's a
interesting point.

Building on that, I thought about it a bit more. While in theory the compiler
might be able to help us here, some of the information inside
mempolicy_slab_node() seems only could be determined at runtime. So I suspect
the compiler might not be able to infer that the two code blocks are equivalent
and deduplicate it.

> 
> > 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.

Thanks!

> 
> > 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.

Yes, this make sense. it's only for strict numa mode.

> 
> perhaps apply_strict_numa[_policy]() will be a better name?

Agree, apply_strict_numa_policy is indeed a better name!

-- 
Thanks,
Hao