Re: [PATCH 1/2] mm: slub: allocate slab object extensions non-contiguously

[Kent Overstreet <kent.overstreet@linux.dev>]

On Tue, May 20, 2025 at 02:46:14PM +0100, Usama Arif wrote:
> 
> 
> On 20/05/2025 14:44, Kent Overstreet wrote:
> > On Tue, May 20, 2025 at 01:25:46PM +0100, Usama Arif wrote:
> >> When memory allocation profiling is running on memory bound services,
> >> allocations greater than order 0 for slab object extensions can fail,
> >> for e.g. zs_handle zswap slab which will be 512 objsperslab x 16 bytes
> >> per slabobj_ext (order 1 allocation). Use kvcalloc to improve chances
> >> of the allocation being successful.
> >>
> >> Signed-off-by: Usama Arif <usamaarif642@gmail.com>
> >> Reported-by: Vlad Poenaru <vlad.wing@gmail.com>
> >> Closes: https://lore.kernel.org/all/17fab2d6-5a74-4573-bcc3-b75951508f0a@gmail.com/
> >> ---
> >>  mm/slub.c | 2 +-
> >>  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/mm/slub.c b/mm/slub.c
> >> index dc9e729e1d26..bf43c403ead2 100644
> >> --- a/mm/slub.c
> >> +++ b/mm/slub.c
> >> @@ -1989,7 +1989,7 @@ int alloc_slab_obj_exts(struct slab *slab, struct kmem_cache *s,
> >>  	gfp &= ~OBJCGS_CLEAR_MASK;
> >>  	/* Prevent recursive extension vector allocation */
> >>  	gfp |= __GFP_NO_OBJ_EXT;
> >> -	vec = kcalloc_node(objects, sizeof(struct slabobj_ext), gfp,
> >> +	vec = kvcalloc_node(objects, sizeof(struct slabobj_ext), gfp,
> >>  			   slab_nid(slab));
> > 
> > And what's the latency going to be on a vmalloc() allocation when we're
> > low on memory?
> 
> Would it not be better to get the allocation slighly slower than to not get
> it at all?

Our behaviour when thrashing sucks, we don't want to do anything to make
that worse.

There's also the fact that vmalloc doesn't correctly respect gfp flags,
so until that gets fixed this doesn't work at all.