Re: [RFC PATCH 1/2] rcu: Add rcu_read_lock_notrace()
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Date: 2025-07-17 17:38:46
Also in:
bpf, linux-rt-devel, rcu
From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Date: 2025-07-17 17:38:46
Also in:
bpf, linux-rt-devel, rcu
On 2025-07-17 12:02, Alexei Starovoitov wrote:
On Thu, Jul 17, 2025 at 8:55 AM Steven Rostedt [off-list ref] wrote:quoted
On Thu, 17 Jul 2025 11:40:28 -0400 Steven Rostedt [off-list ref] wrote:quoted
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.BTW, if we can't solve this issue and something else came along and attached to tracepoints that caused unbounded latency, I would also argue that whatever came along would need to be prevented from being configured with PREEMPT_RT. My comment wasn't a strike against BPF programs; It was a strike against something adding unbounded latency into a critical section that has preemption disabled.Stop blaming the users. Tracepoints disable preemption for now good reason and you keep shifting the blame. Fix tracepoint infra.
I think we're all agreeing here that it's the tracepoint instrumentation infrastructure that needs to be changed to become more RT friendly, and that BPF is merely the tracepoint user that happens to have the longest running callbacks at the moment. So AFAIU there is no blame on BPF here, and no expectation for any changes in BPF neither. Thanks, Mathieu -- Mathieu Desnoyers EfficiOS Inc. https://www.efficios.com