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

[Sun YangKai]

On 2026/6/30 07:09, David Sterba wrote:
> 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.

Oh, I've missed that. Then things seems good for me.

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

And I have

❯ sudo grep 2112 /proc/slabinfo
sighand_cache        593   1335   2112   15   8

on my system :)

Thanks,
Sun YangKai