On Mon, Jul 04, 2022 at 09:34:23PM +0100, Matthew Wilcox wrote: > On Mon, Jun 27, 2022 at 12:03:08AM -0700, Christoph Hellwig wrote: > > I'd suggest you discuss you needs with the slab mainainers and the mm > > community firs. > > > > On Wed, Jun 22, 2022 at 05:32:25PM -0700, Alexei Starovoitov wrote: > > > From: Alexei Starovoitov <ast@xxxxxxxxxx> > > > > > > Introduce any context BPF specific memory allocator. > > > > > > Tracing BPF programs can attach to kprobe and fentry. Hence they > > > run in unknown context where calling plain kmalloc() might not be safe. > > > Front-end kmalloc() with per-cpu per-bucket cache of free elements. > > > Refill this cache asynchronously from irq_work. > > I can't tell from your description whether a bump allocator would work > for you. That is, can you tell which allocations need to persist past > program execution (and use kmalloc for them) and which can be freed as > soon as the program has finished (and can use the bump allocator)? > > If so, we already have one for you, the page_frag allocator > (Documentation/vm/page_frags.rst). It might need to be extended to meet > your needs, but it's certainly faster than the kmalloc allocator. Already looked at it, and into mempool, and everything we could find. All 'normal' allocators sooner or later synchornously call into page_alloc, kasan, memleak and other debugging facilites that grab locks which make them unusable for bpf tracing progs. The main difference of bpf specific alloc vs the rest is bpf_mem_alloc from the cache and refill of the cache are two asynchronous operations. It allows the former to be reentrant and nmi safe. The speed of bpf mem alloc is secondary here. The lock less free list is there to absorb async refill. irq_work_queue is not instant while bpf prog might do several bpf_mem_alloc before irq_work has a chance to refill. We're thinking about self adjusting low/high watermarks that will be tunned by the bpf verifier that has visibility into what program is going to do.
