Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1738882
| From | Steven Rostedt <rostedt@goodmis.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH v6 2/2] tracing: Add support for preempt and irq enable/disable events |
| Date | 2017-09-25 12:20 +0200 |
| Message-ID | <utyEx-4YG-3@gated-at.bofh.it> (permalink) |
| References | <uslq1-8rR-3@gated-at.bofh.it> <uslq1-8rR-1@gated-at.bofh.it> <uss8b-4hz-43@gated-at.bofh.it> <usAS5-ZW-15@gated-at.bofh.it> <utx5M-3Sb-5@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Mon, 25 Sep 2017 10:34:32 +0200
Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > grep-1041 [002] d..1 80.363455: preempt_disable:
> > caller=_raw_spin_lock_irqsave+0x1d/0x40
> > parent=add_wait_queue+0x15/0x50
>
> I suppose that sort-of makes sense for the preempt-tracer, but its a
> weird thing for a generic tracepoint.
I still find it very useful, even as a tracepoint.
>
> > >> void start_critical_timings(void)
> > >> {
> > >> + if (this_cpu_read(tracing_preempt_cpu))
> > >> + trace_preempt_enable_rcuidle(CALLER_ADDR0, CALLER_ADDR1);
> > >> +
> > >> + if (this_cpu_read(tracing_irq_cpu))
> > >> + trace_irq_enable_rcuidle(CALLER_ADDR0, CALLER_ADDR1);
> > >> +
> > >> start_critical_timings_tracer();
> > >> }
> > >> EXPORT_SYMBOL_GPL(start_critical_timings);
> > >>
> > >> void stop_critical_timings(void)
> > >> {
> > >> + if (this_cpu_read(tracing_preempt_cpu))
> > >> + trace_preempt_disable_rcuidle(CALLER_ADDR0, CALLER_ADDR1);
> > >> +
> > >> + if (this_cpu_read(tracing_irq_cpu))
> > >> + trace_irq_disable_rcuidle(CALLER_ADDR0, CALLER_ADDR1);
> > >> +
> > >> stop_critical_timings_tracer();
> > >> }
> > >> EXPORT_SYMBOL_GPL(stop_critical_timings);
> > >
> > > And I feel these yield somewhat odd semantics, does that need explaining
> > > somewhere?
> >
> > Maybe I can add a comment here, if you prefer that. When you meant
> > semantics, do you mean 'critical' vs 'atomic' thing or do you mean the
> > semantics/context of how this function is supposed to be used?
>
> I would add the comment to the tracepoint definition.
>
> On semantics, the whole stop/start excludes a fair bunch of walltime
> from our measurement, I feel that needs to be called out and enumerated
> (when time goes missing and why).
>
> Given that the idle thread runs with preempt-off I understand its
> purpose from the POV from the preempt-tracer, but its 'weird' behaviour
> if you're looking at it from a pure tracepoint pov.
You mean you want to trace all calls to preempt and irq off even if
preempt and irqs are already off?
>
> > >> void trace_preempt_off(unsigned long a0, unsigned long a1)
> > >> {
> > >> + if (this_cpu_read(tracing_preempt_cpu))
> > >> + return;
> > >> +
> > >> + this_cpu_write(tracing_preempt_cpu, 1);
> > >> +
> > >> + trace_preempt_disable_rcuidle(a0, a1);
> > >> tracer_preempt_off(a0, a1);
> > >> }
> > >> #endif
> > >
> > > And here you assume things like double on / double off don't happen,
> > > which might well be so, but does seem somewhat fragile.
> > >
> >
> > We are handling the cases where these functions might be called twice,
> > but we are only interested in the first time they're called. I caught
> > a dead lock happen when I didn't add such protection to
> > trace_hardirqs_off so I added to these to the trace_hardirqs* and
> > trace_preempt* ones as well to just to be extra safe and keep it
> > consistent. Hope I understood your concern correctly, if not please
> > let me know, thanks.
>
> Under what conditions where they called twice? That seems like something
> that should not happen to begin with. Esp the one I left quoted above,
> disabling when its already disabled sounds like fail. So please provide
> more details on the scenario you're working around.
I'm a little confused by this too.
-- Steve
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[PATCH v6 2/2] tracing: Add support for preempt and irq enable/disable events Joel Fernandes <joelaf@google.com> - 2017-09-22 04:00 +0200
Re: [PATCH v6 2/2] tracing: Add support for preempt and irq enable/disable events Peter Zijlstra <peterz@infradead.org> - 2017-09-22 11:10 +0200
Re: [PATCH v6 2/2] tracing: Add support for preempt and irq enable/disable events Joel Fernandes <joelaf@google.com> - 2017-09-22 20:30 +0200
Re: [PATCH v6 2/2] tracing: Add support for preempt and irq enable/disable events Peter Zijlstra <peterz@infradead.org> - 2017-09-25 10:40 +0200
Re: [PATCH v6 2/2] tracing: Add support for preempt and irq enable/disable events Steven Rostedt <rostedt@goodmis.org> - 2017-09-25 12:20 +0200
Re: [PATCH v6 2/2] tracing: Add support for preempt and irq enable/disable events Peter Zijlstra <peterz@infradead.org> - 2017-09-25 12:40 +0200
Re: [PATCH v6 2/2] tracing: Add support for preempt and irq enable/disable events Steven Rostedt <rostedt@goodmis.org> - 2017-09-25 13:00 +0200
Re: [PATCH v6 2/2] tracing: Add support for preempt and irq enable/disable events Joel Fernandes <joelaf@google.com> - 2017-09-26 01:00 +0200
Re: [PATCH v6 2/2] tracing: Add support for preempt and irq enable/disable events Steven Rostedt <rostedt@goodmis.org> - 2017-09-26 04:50 +0200
Re: [PATCH v6 2/2] tracing: Add support for preempt and irq enable/disable events Joel Fernandes <joelaf@google.com> - 2017-09-26 02:30 +0200
csiph-web