Re: [PATCH v6 2/2] tracing: Add support for preempt and irq enable/disable events

[Peter Zijlstra]

On Mon, Sep 25, 2017 at 06:15:28AM -0400, Steven Rostedt wrote:
> On Mon, 25 Sep 2017 10:34:32 +0200
> Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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.

Didn't say anything about useful, just that it might not be expected.

> > 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?

Sure, why not? This stuff naturally nests, and who is to say its not a
useful thing to trace all of them?

By also tracing the nested sections you can, for instance, see how much
you'd really win by getting rid of the outer one. If, for instance, the
outer only accounts for 1% of the time, while the inner ones are
interlinked and span the other 99%, there's more work to do than if that
were not the case.