Hi, On 11/17/2024 12:42 AM, Alexei Starovoitov wrote: > 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 have been working on it since last week [1] and have already written a patch (a patch in a patch set) for it. In my patch, these two allocators will be merged if they are mergable and now the merge is decided by the return value of kmalloc_size_roundup(). Also considering about using bpf_global_ma instead, but the biggest problem for bpf_global_ma is the memory accounting. The allocated memory will be accounted under root memory cgroup instead of the memory cgroup of users. [1]: https://lore.kernel.org/bpf/e14d8882-4760-7c9c-0cfc-db04eda494ee@xxxxxxxxxxxxxxx/ > >> 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/ > > .
