lkml.org 
[lkml]   [2020]   [Mar]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: Instrumentation and RCU
On Mon, Mar 9, 2020 at 11:15 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Mon, 09 Mar 2020 18:02:32 +0100
> Thomas Gleixner <tglx@linutronix.de> wrote:
>
[...]
> > #3) RCU idle
> >
> > Being able to trace code inside RCU idle sections is very similar to
> > the question raised in #1.
> >
> > Assume all of the instrumentation would be doing conditional RCU
> > schemes, i.e.:
> >
> > if (rcuidle)
> > ....
> > else
> > rcu_read_lock_sched()
> >
> > before invoking the actual instrumentation functions and of course
> > undoing that right after it, that really begs the question whether
> > it's worth it.
> >
> > Especially constructs like:
> >
> > trace_hardirqs_off()
> > idx = srcu_read_lock()
> > rcu_irq_enter_irqson();
> > ...
> > rcu_irq_exit_irqson();
> > srcu_read_unlock(idx);
> >
> > if (user_mode)
> > user_exit_irqsoff();
> > else
> > rcu_irq_enter();
> >
> > are really more than questionable. For 99.9999% of instrumentation
> > users it's absolutely irrelevant whether this traces the interrupt
> > disabled time of user_exit_irqsoff() or rcu_irq_enter() or not.
> >
> > But what's relevant is the tracer overhead which is e.g. inflicted
> > with todays trace_hardirqs_off/on() implementation because that
> > unconditionally uses the rcuidle variant with the scru/rcu_irq dance
> > around every tracepoint.
> >
> > Even if the tracepoint sits in the ASM code it just covers about ~20
> > low level ASM instructions more. The tracer invocation, which is
> > even done twice when coming from user space on x86 (the second call
> > is optimized in the tracer C-code), costs definitely way more
> > cycles. When you take the scru/rcu_irq dance into account it's a
> > complete disaster performance wise.
>
> Is this specifically to do with the kernel/trace/trace_preemptirqs.c code
> that was added by Joel?

Just started a vacation here and will be back on January 12th. Will
take a detailed look at Thomas's email at that time.

Adding some more folks (Daniel, Valentin) who have used the
preempt/irq tracepoints.

I agree we should reorder things and avoid these circular
dependencies, it bothers me too. I am happy to help with any clean ups
related to it. Let us definitely discuss more and fix it. Thanks.

- Joel

\
 
 \ /
  Last update: 2020-03-09 19:43    [W:0.241 / U:9.568 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site