Re: [PATCH] btrfs: compression: allocate buckets with workspace

[David Sterba]

On Mon, Jun 29, 2026 at 09:54:11AM +0800, Sun YangKai wrote:
> > -	ws = kzalloc_obj(*ws);
> > +	ws = kzalloc(struct_size(ws, bucket, BUCKET_SIZE * 2), GFP_KERNEL);
> 
> It seems that size is fixed and known at compile time, and since we want 
> to inline the buckets in the struct, I think we can have something like 
> this to save one pointer:
> 
> struct heuristic_ws {
> 	...
> 	struct bucket_item bucket[BUCKET_SIZE];
> 	struct bucket_item bucket_b[BUCKET_SIZE];

I like this idea, given that we know the size at compile time.

> }
> 
> However, each bucket array takes exactly 1024B memory. Currently we have 
> a 48B allocation for the struct it self, 2 * 1024B allocation for bucket 
> array, and 8192B allocation for sample. With these 2 arrays inlined, the 
> struct will need 32 + 2048B allocation if my calculation is correct, 
> which will goes into kmalloc-4k. Seems not good.

SLUB merges same/similar sized structures for the named caches, I'm not
sure if this also works for the generic slabs. We can add the kmem cache
and so we can utilize the merging.

The sharing can be seen in /sys/kernel/slab, "ls -l | grep <SIZE>". The
size is rounded up to hw cacheline, so for the heuristic workspace it'll
end up in size 2112. I see at least one existing named slab on my
system, 'dmaengine-unmap-256'. This may not matter, but a named cache
can fix the slack space in the 4k slab.