On Thu, 17 Jul 2025 08:27:24 -0700 Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > On Thu, Jul 17, 2025 at 8:12 AM Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > > > > On Thu, 17 Jul 2025 07:57:27 -0700 > > Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > > > > > I still don't understand what problem is being solved. > > > As current tracepoint code stands there is no issue with it at all > > > on PREEMPT_RT from bpf pov. > > > bpf progs that attach to tracepoints are not sleepable. > > Stop this fud, please. No fud. Above you said they are not sleepable. I guess that just means they don't call schedule? > > bpf progs were preemptible for years and had no issue in RT. > tracepoints are using preempt_disable() still and that's a > tracepoint infra problem. Nothing to do with users of tracepoints. Yes, it is a tracepoint infra problem that we are trying to solve. The reason we are trying to solve it is because BPF programs can extend the time a tracepoint takes. If anything else extended the time, this would need to be solved as well. But currently it's only BPF programs that cause the issue. Let me explain the problem being solved then. Tracepoints currently disable preemption with preempt_disable_notrace() to allow things to be synchronized correctly. But with the disabling of preemption for the users of tracepoints (BPF programs being one of them), it can result in large latency for RT tasks. The request is to use RCU instead as RCU in PREEMPT_RT can be preempted. That means we need a rcu_read_lock_notrace() version. One that doesn't call into any tracing infrastructure (like current rcu_read_lock() does), otherwise there could be an infinite recursion. The discussion at hand is how do we come up with a rcu_read_lock_notrace(), and using rcu_read_lock_fast() may be one of the solutions as it can be implemented without triggering tracing infrastructure. Does that explain it better? -- Steve
