Re: [PATCH bpf-next v2 3/7] selftests/bpf: libarena: Add buddy per-CPU caches

["Kumar Kartikeya Dwivedi" <memxor@gmail.com>]

On Fri Oct 23, 2026 at 1:40 AM CEST, Emil Tsalapatis wrote:
> On Thu Oct 22, 2026 at 12:53 PM UTC, Harry Yoo wrote:
>> On Wed, Oct 21, 2026 at 11:26:37PM +0000, Emil Tsalapatis wrote:
>>> Every small allocation currently reaches the central buddy allocator and
>>> takes its lock. This serializes otherwise independent callers and touches
>>> the buddy metadata on every allocation and free.
>>>
>>> Add a fixed-size LIFO array for each cached order and CPU. Keep the
>>> per-CPU cache pointers in struct buddy and allocate each CPU's packed
>>> cache from the buddy during initialization. Cache the eight smallest
>>> allocation orders, up to 2 KiB. Each array holds 16 objects, bounding each
>>> CPU's cache to about 1.5 KiB.
>>
>> TIL the min alloc size is not PAGE_SIZE in BPF buddy allocator :)
>>
>>> Allocations pop from the local array and frees push onto it without taking
>>> the buddy lock. Empty and full arrays fall through to the central buddy
>>> allocator. Packed arrays keep the fast path to a bounds check and a single
>>> slot access.
>>>
>>> BPF programs only disable migration, so another task can preempt a cache
>>> operation and run on the same CPU, and an IRQ or NMI program can interrupt
>>> one. Claim the CPU with a cmpxchg on a per-CPU flag before touching its
>>> arrays, following the model used by the main BPF memory allocator. An
>>> operation that finds the CPU already claimed falls through to the central
>>> buddy allocator.
>>>
>>> Signed-off-by: Emil Tsalapatis <emil@etsalapatis.com>
>>> ---
> [...]
>
> We don't really have cmpxchg_local() available in BPF. I hacked up a prototype
> and the benefits were actually not that significant, about 2ns for hot alloc
> free loops.
>
>>
>> On x86, cmpxchg instruction should be cheaper without LOCK prefix.
>>
>>> +
>>> +	return cache;
>>> +}
>>> +
>>> +static __always_inline void buddy_cache_exit(struct buddy_cache __arena *cache)
>>> +{
>>> +	smp_store_release(&cache->active, 0);
>>> +}
>>
>> We don't need this barrier because this is percpu?
>
>
> ... this, however did matter significantly for hot loop frees. I will add it
> to v3 and respin.

What architecture are you measuring it on? Because on x86 smp_store_release() is
equivalent to a WRITE_ONCE(), so unless this was suppressing compiler
optimizations and the code changed by doing a simple store, I don't follow how
it would help.