On Sat, Nov 16, 2024 at 8:15 AM Thomas Weißschuh <linux@xxxxxxxxxxxxxx> wrote: > > On 2024-11-16 08:01:49-0800, Alexei Starovoitov wrote: > > On Sat, Nov 16, 2024 at 1:21 AM Sebastian Andrzej Siewior > > <bigeasy@xxxxxxxxxxxxx> wrote: > > > > > > On 2024-11-15 23:29:31 [+0100], Thomas Gleixner wrote: > > > > IIRC, BPF has it's own allocator which can be used everywhere. > > > > > > Thomas Weißschuh made something. It appears to work. Need to take a > > > closer look. > > > > Any more details? > > bpf_mem_alloc is a stop gap. > > It is indeed using bpf_mem_alloc. > It is a fairly straightforward conversion, using one cache for > intermediate and one for non-intermediate nodes. Sounds like you're proposing to allocate two lpm specific bpf_ma-s ? Just use bpf_global_ma. More ma-s means more memory pinned in bpf specific freelists. That's the main reason to teach slub and page_alloc about bpf requirements. All memory should be shared by all subsystems. Custom memory pools / freelists, whether it's bpf, networking or whatever else, is a pain point for somebody. The kernel needs to be optimal for all use cases. > I'll try to send it early next week. Looking forward. > > As Vlastimil Babka suggested long ago: > > https://lwn.net/Articles/974138/ > > "...next on the target list is the special allocator used by the BPF > > subsystem. This allocator is intended to succeed in any calling > > context, including in non-maskable interrupts (NMIs). BPF maintainer > > Alexei Starovoitov is evidently in favor of this removal if SLUB is > > able to handle the same use cases..." > > > > Here is the first step: > > https://lore.kernel.org/bpf/20241116014854.55141-1-alexei.starovoitov@xxxxxxxxx/
