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 4:24 PM EDT, Matt Bobrowski wrote:
> On Thu, Apr 23, 2026 at 12:43:13PM -0400, Emil Tsalapatis wrote:
>> 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.
>
> Both sound like relatively good ideas to me. Notably, this point has
> sparked another thing that I was kinda curious about. Do you envision
> libarena being hosted outside of the Linux kernel source tree at some
> point? TBH, I think it'd be quite nice if it was. I definitely
> envision something like libarena being a submodule within numerous
> other BPF-enabled projects.
>

Exactly, that is the plan. After the change lands we can periodically
sync the changes from the kernel tree to an external repo (e.g.,
Github). I am thinking of reusing libbpf's export process since it works
pretty well, but the details are still open for discussion.

> Also, I kindly request that you CC me on any future revisions and
> changes to libarena.

Gladly! I will be sending another version today (that also incorporates
your feedback on patch 2/8).