Messages in this thread | | | Date | Mon, 26 Oct 2020 16:44:59 -0400 | From | Steven Rostedt <> | Subject | Re: [RFC PATCH 6/6] tracing: use sched-RCU instead of SRCU for rcuidle tracepoints |
| |
On Mon, 26 Oct 2020 10:28:07 -0400 (EDT) Mathieu Desnoyers <mathieu.desnoyers@efficios.com> wrote:
> I agree with Peter. Removing the trace_.*_rcuidle weirdness from the tracepoint > API and fixing all callers to ensure they trace from a context where RCU is > watching would simplify instrumentation of the Linux kernel, thus making it harder > for subtle bugs to hide and be unearthed only when tracing is enabled. This is
Note, the lockdep RCU checking of a tracepoint is outside of it being enabled or disable. So if a non rcuidle() tracepoint is in a location that RCU is not watching, it will complain loudly, even if you don't enable that tracepoint.
> AFAIU the general approach Thomas Gleixner has been aiming for recently, and I > think it is a good thing. > > So if we consider this our target, and that the current state of things is that > we need to have RCU watching around callback invocation, then removing the > dependency on SRCU seems like an overall simplification which does not regress > feature-wise nor speed-wise compared with what we have upstream today. The next > steps would then be to audit all rcuidle tracepoints and make sure the context > where they are placed has RCU watching already, so we can remove the tracepoint
Just remove the _rcuidle() from them, and lockdep will complain if they are being called without RCU watching.
-- Steve
> rcuidle API. That would effectively remove the calls to rcu_irq_{enter,exit}_irqson > from the tracepoint code. > > This is however beyond the scope of the proposed patch set. > > Thanks, > > Mathieu >
| |