Re: [PATCH bpf-next v8 6/8] selftests/bpf: Add buddy allocator for libarena

["Emil Tsalapatis" <emil@etsalapatis.com>]

On Thu Apr 23, 2026 at 10:00 AM EDT, Kumar Kartikeya Dwivedi wrote:
> On Thu, 23 Apr 2026 at 10:44, Matt Bobrowski <mattbobrowski@google.com> wrote:
>>
>> On Tue, Apr 21, 2026 at 12:50:35PM -0400, Emil Tsalapatis wrote:
>> > Add a byte-oriented buddy allocator for libarena. The buddy
>> > allocator provides an alloc/free interface for small arena allocations
>> > ranging from 16 bytes to 512 KiB. Lower allocations values are rounded
>> > up to 16 bytes. The buddy allocator does not handle larger allocations
>> > that can instead use the existing bpf_arena_{alloc, free}_pages() kfunc.
>> >
>> > Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com>
>>
>> The implementation of this BPF arena backed buddy allocator looks
>> rather solid. I noticed that we have a single global lock being used
>> here to synchronize metadata structure modifications. Have you thought
>> about how this might be a high contention point, particularly when
>> dealing with systems with incredibly high CPU core counts? Did you
>> consider possibly making use of localized per-CPU caches for the most
>> common/small allocation sizes or something like that? This is
>> something that definitely crossed my mind when I was initially
>> thinking about implementing something like this a while back. I
>> understand that this is an initial implementation, so it doesn't
>> necessarily carry all the bells and whistles, but I was curious to
>> know whether this had also crossed your mind and what your thoughts
>> were on it.
>
> Yes, both reentrancy protection and a per-CPU caches are things Emil
> is planning to work on next.
>
>>
>> [...]

Can confirm. This is basically just the first version of the allocator
just so we have some way to manage arena memory without hacks. The first
thing to optimize is adding per-CPU caches to avoid contention. I've
avoided adding them until now for two reasons:

1) We don't really have arena workloads we can test optimizations
against. I am working on porting microbenchmarks from userspace
allocators so we can concretely see the effect of any features we add.
I'm also working on adding data structures to libarena, and since they
may do allocations/frees during regular operations we can use them for
benchmarking.

2) Until recently there's been limits to how complex an arena program could be.
The allocator by itself would exhaust the BPF call stack, so adding more features
would cause it to fail verification. With recent kernels this is not an issue so
we can move forward with more features.