Re: [EXT.MSG] Re: [PATCH RFC bpf-next 0/2] bpf: Do not let preemption cause false recursion drops in trampoline progs

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

On Thu Nov 5, 2026 at 12:12 AM UTC, Mike Bazov wrote:
> On Wed, Nov 04, 2026 at 02:20 AM Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
>    > Add bpf_preempt_disable().
>    > Your test forces the preemption in the middle of the prog.
>    > Explicit bpf_preempt_disable() will fix it.
>
>    I tried it, and with the whole prog body wrapped in bpf_preempt_disable() /
>    bpf_preempt_enable(), Task B is still skipped in every round (on a 7.0
>    kernel, 20 rounds, fentry and fexit: runs_b=0, recursion_misses=20).
>
>    perf record -e sched:sched_switch -g shows where Task A is switched out
>    now, 20 of 20 (Task A, SCHED_OTHER, preempted by Task B, SCHED_FIFO):
>
>      __schedule+0x48f
>      preempt_schedule+0x59
>      preempt_schedule_thunk+0x16
>      bpf_preempt_enable+0x1c
>      bpf_trampoline_6442539626+0x105
>      bpf_prog_7dd04eadc26e277d_on_fentry+0x11
>      bpf_trampoline_6442539626+0x192
>      __set_task_comm+0x5
>
>    That is still inside the prog, while prog->active is held.

Right. Pls hack bpf_preempt_enable() to use preempt_enable_no_resched().
I think recursion misses may disappear or become single digit.
If it's good enough we can quickly add bpf_preempt_enable_no_resched() kfunc.

Also try NO_HRTICK in /sys/kernel/debug/sched/features.
That may be decent workaround for now.

>    > What are run_cnt and recursion_misses of your progs on inet_sendmsg()
>    > and inet_recvmsg() in production?
>
>    We hit this while testing new distros with 7.0 kernels, so we don't
>    have fleet numbers for these counters yet. For our inet_sendmsg/recvmsg
>    progs, in testing: fentry/fexit on inet[6]_{send,recv}msg, Ubuntu 24.04
>    with its stock 7.0 HWE kernel (7.0.0-38-generic, default lazy
>    preemption, 4 vCPUs), behind nginx -> gunicorn -> redis, with wrk from
>    another machine (128 keep-alive connections, ~1.07M requests over 10
>    minutes, ~62% CPU):
>
>      run_cnt 38040015, recursion_misses 4063

hmm. you really cannot tolerate that small drop? it's tracing at the end.
It would be a different story if such drops were on lsm hook.

let's try to think how per-task counter would work.
I'm guessing 128 connections is 128 threads servicing them,
so 200 cpus will be hammering the same per-task counter which will
cause real perf loss.
Gotta do better than per-task.
Also it needs to be per-task + per-prog. How will it look like?