Re: [PATCH bpf-next 0/5] bpf: BPF specific memory allocator.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 28 Jun 2022, Alexei Starovoitov wrote:

> > That is a relatively new feature due to RT logic support. without RT this
> > would be a simple irq disable.
>
> Not just RT.
> It's a slow path:
>         if (IS_ENABLED(CONFIG_PREEMPT_RT) ||
>             unlikely(!object || !slab || !node_match(slab, node))) {
>               local_unlock_irqrestore(&s->cpu_slab->lock,...);
> and that's not the only lock in there.
> new_slab->allocate_slab... alloc_pages grabbing more locks.


Its not a lock for !RT.

The fastpath is lockless if hardware allows that but then we go into more
and more serialiation needs as the allocation gets more into the page
allocator logic.

> > allocation functions in the BPF logic like bpf_mem_alloc? How do you stop
> > that from happening?
>
> here is the comment in the patch:
> /* notrace is necessary here and in other functions to make sure
>  * bpf programs cannot attach to them and cause llist corruptions.
>  */

"notrace".... Ok Hmmm...



[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux