Re: [PATCH 3/3] slab: free remote objects to sheaves on memoryless nodes

[Harry Yoo]

On Wed, Mar 11, 2026 at 09:25:57AM +0100, Vlastimil Babka (SUSE) wrote:
> On memoryless nodes we can now allocate from cpu sheaves and refill them
> normally. But when a node is memoryless on a system without actual
> CONFIG_HAVE_MEMORYLESS_NODES support, freeing always uses the slowpath
> because all objects appear as remote. We could instead benefit from the
> freeing fastpath, because the allocations can't obtain local objects
> anyway if the node is memoryless.
> 
> Thus adapt the locality check when freeing, and move them to an inline
> function can_free_to_pcs() for a single shared implementation.
> 
> On configurations with CONFIG_HAVE_MEMORYLESS_NODES=y continue using
> numa_mem_id() so the percpu sheaves and barn on a memoryless node will
> contain mostly objects from the closest memory node (returned by
> numa_mem_id()). No change is thus intended for such configuration.
> 
> On systems with CONFIG_HAVE_MEMORYLESS_NODES=n use numa_node_id() (the
> cpu's node) since numa_mem_id() just aliases it anyway. But if we are
> freeing on a memoryless node, allow the freeing to use percpu sheaves
> for objects from any node, since they are all remote anyway.
> 
> This way we avoid the slowpath and get more performant freeing.

> The potential downside is that allocations will obtain objects with a larger
> average distance. If we kept bypassing the sheaves on freeing, a refill
> of sheaves from slabs would tend to get closer objects thanks to the
> ordering of the zonelist.

When I think about ways to avoid this, the right solution is to
implement HAVE_MEMORYLESS_NODES :)

> Architectures that allow de-facto memoryless
> nodes without proper CONFIG_HAVE_MEMORYLESS_NODES support should perhaps
> consider adding such support.

Exactly!

> Signed-off-by: Vlastimil Babka (SUSE) <vbabka@xxxxxxxxxx>
> ---

Looks good to me,
Reviewed-by: Harry Yoo <harry.yoo@xxxxxxxxxx>

-- 
Cheers,
Harry / Hyeonggon