Re: linux-next: manual merge of the rcu tree with the ftrace tree

[Sebastian Andrzej Siewior <bigeasy@linutronix.de>]

On 2025-11-14 09:00:21 [-0800], Paul E. McKenney wrote:
> > > Where in PREEMPT_RT we do not disable preemption around the tracepoint
> > > callback, but in non RT we do. Instead it uses a srcu and migrate disable.
> > 
> > I appreciate the effort. I really do. But why can't we have SRCU on both
> > configs?
> 
> Due to performance concerns for non-RT kernels and workloads, where we
> really need preemption disabled.

This means srcu_read_lock_notrace() is much more overhead compared to
rcu_read_lock_sched_notrace()?
I am a bit afraid of different bugs here and there.

> > Also why does tracepoint_guard() need to disable migration? The BPF
> > program already disables migrations (see for instance
> > bpf_prog_run_array()).
> > This is true for RT and !RT. So there is no need to do it here.
> 
> The addition of migration disabling was in response to failures, which
> this fixed.  Or at least greatly reduced the probability of!  Let's see...
> That migrate_disable() has been there since 2022, so the failures were
> happening despite it.  Adding Yonghong on CC for his perspective.

Okay. In general I would prefer that we know why we do it. BPF had
preempt_disable() which was turned into migrate_disable() for RT reasons
since remaining on the same CPU was enough and preempt_disable() was the
only way to enforce it at the time.
And I think Linus requested migrate_disable() to work regardless of RT
which PeterZ made happen (for different reasons, not BPF related).

> 							Thanx, Paul

Sebastian