Re: [PATCH v5] tracing: Guard __DECLARE_TRACE() use of __DO_TRACE_CALL() with SRCU-fast

[Steven Rostedt <rostedt@goodmis.org>]

On Fri, 9 Jan 2026 14:18:36 -0800
Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:

> On Fri, Jan 9, 2026 at 2:00 PM Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > On Fri, 9 Jan 2026 13:54:34 -0800
> > Alexei Starovoitov <alexei.starovoitov@gmail.com> wrote:
> >  
> > > On Fri, Jan 9, 2026 at 12:21 PM Mathieu Desnoyers
> > > <mathieu.desnoyers@efficios.com> wrote:  
> > > >
> > > >
> > > > * preempt disable/enable pair:                                     1.1 ns
> > > > * srcu-fast lock/unlock:                                           1.5 ns
> > > >
> > > > CONFIG_RCU_REF_SCALE_TEST=y
> > > > * migrate disable/enable pair:                                     3.0 ns  
> > >
> > > .. and you're arguing that 3ns vs 1ns difference is so important
> > > for your out-of-tree tracer that in-tree tracers need to do
> > > some workarounds?! wtf  
> >
> > This has nothing to do with out of tree tracers. The overhead of the
> > 22ns is for any tracepoint in an in-tree module. That's because the
> > rq->nr_pinned isn't exported for modules to use.  
> 
> None of the driver's tracepoints are in the critical path.
> You perfectly know that Mathieu argued about not slowing down lttng.

How is this about lttng? Sure he cares about that, but even tracepoints
that lttng uses doesn't get affected any more than ftrace or bpf.
Because lttng is one of the callbacks. The migrate disable happens in
the in-tree portion of the code.

So you are saying that all the tracepoints for xfs are not in a fastpath?

-- Steve