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

[Matt Bobrowski <mattbobrowski@google.com>]

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.

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