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

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

On Wed, Jun 24, 2026 at 02:14:55PM +0900, Harry Yoo wrote:
> 
> 
> On 6/23/26 8:04 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 code snippets.
> 
> Right.
> 
> > Introduce a helper function to resolve the NUMA policy once, eliminating
> > the duplicated code and reducing execution overhead.
> 
> Nice.
> 
> > Also remove __slab_alloc_node() function because it is almost empty.
> 
> Nice!
> 
> > The callers of __slab_alloc_node now call ___slab_alloc() directly.
> > 
> > Additional notes:
> > 
> >   Previously, when slab_strict_numa was enabled, alloc_from_pcs() and
> >   __slab_alloc_node() could each resolve the task mempolicy, so
> >   MPOL_INTERLEAVE or MPOL_WEIGHTED_INTERLEAVE could advance the
> >   interleave state twice for a single object allocation attempt.
> >
> >   With this change, the strict NUMA node is resolved once and reused by
> >   both alloc_from_pcs() and ___slab_alloc().
> 
> Nice catch!
> 
> >   This is a behavior change, but it better matches the intent of
> >   selecting one policy node for one allocation attempt.
> 
> Right.
> 
> and I think backporting is unnecessary here.
> 
> > Signed-off-by: Hao Li <hao.li@linux.dev>
> > ---
> > Changes in v2:
> >   * Use a better function name apply_strict_numa_policy() (Thanks Harry)
> >   * Remove almost empty function __slab_alloc_node.
> >   * Add a local variable, strict_node, so the retry path in
> >     __kmalloc_nolock_noprof() computes the strict NUMA node from the original
> >     node parameter instead of a previously resolved node value.
> 
> What about overriding 'node' before retry label instead?
> 
>         node = apply_strict_numa_policy(node);
>         [...]
> retry:
>         [...]
> 

I agree! I originally used a separate strict_node variable mostly to keep the
old retry behavior intact. But looking at it now, the retry is really just an
internal fallback for the same requested object allocation. There's no strong
reason to advance the MPOL_INTERLEAVE or MPOL_WEIGHTED_INTERLEAVE state again
on each retry.

> Otherwise LGTM.

Thanks!

-- 
Thanks,
Hao