Re: [PATCH bpf-next v3 5/7] selftests/bpf: libarena: Refill local caches in batches

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Tue, Oct 27, 2026 at 01:57 PM Emil Tsalapatis <emil@etsalapatis.com> wrote:
> On Tue, Oct 27, 2026 at 7:51 PM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
>>
>> On Thu, Oct 22, 2026 at 05:20 PM Emil Tsalapatis <emil@etsalapatis.com> wrote:
>> > +     if (buddy_alloc_bulk(buddy, size, BUDDY_CACHE_BATCH_ORDER,
>> > +                          (void __arena * __arena *)slots->objects))
>> > +             return NULL;
>>
>> This asks for one block of order + 3. When the existing chunks have free
>> objects of this order, but no such block, it goes to buddy_chunk_get().
>> Before this patch the existing chunks served such buddy_alloc().
>>
>> A sleepable prog takes another 1 MiB chunk.
>> A non-sleepable prog loses 1 MiB of buddy->vaddr in every buddy_alloc():
>>
>>   buddy_alloc()                       the cache is empty
>>     buddy_cache_refill()
>>       buddy_alloc_bulk()              no free block of order + 3
>>         buddy_chunk_get()
>>           buddy_alloc_arena_vaddr()   buddy->vaddr += 1 MiB
>>           bpf_arena_free_pages()      deferred to a worker
>>           bpf_arena_alloc_pages()     the range is still reserved: NULL
>>     buddy_alloc_memory()              one object from the existing chunks
>>                                       the cache is still empty
>>
>> After 1024 of them buddy_alloc_arena_vaddr() fails for sleepable progs
>> too.
>>
>> Should the refill look at the existing chunks only,
>> like buddy_alloc_nogrow() in your other series?
>
> I think that'd be a fair policy, the downside would be that
> consecutive allocations
> would fall through the cache, but that's a fair tradeoff. It's easier
> for a user to
> preallocate memory into the allocator from the mapping as opposed to having
> to deal with the fragmentation you're describing.

Thanks. Makes sense to me.