Re: [RFC][PATCH 2/2 v2] tracing: Only trace sched_wakeup if it actually work something up

[Peter Zijlstra <peterz@infradead.org>]

On Wed, 2010-12-08 at 09:06 -0500, Steven Rostedt wrote:
> On Wed, 2010-12-08 at 13:12 +0100, Peter Zijlstra wrote:
> > On Thu, 2010-12-02 at 23:04 -0500, Steven Rostedt wrote:
> > > Currently the tracepoint sched_wakeup traces the wakeup event even
> > > if the wakeup failed to wake anything up. This is quite stupid
> > > but it happens because we did not want to add a conditional
> > > to the core kernel code that would just slow down the wakeup events.
> > > 
> > Its actually quite useful at times, so no, I don't much like this.
> 
> OK, I'll remove this patch. This is why I kept it at the end of the
> queue.
> 
> But I'm curious. Linus ripped into me about the uselessness of this
> event when success was not true. What use do you see of this tracepoint
> when a wake up does not happen? I, personally, just filter these out.

Oh, some wake-up race like scenarios. Either when there's multiple
wakeups or things where the task was preempted and didn't need the full
wakeup.

There's also a sleep race, where the wakeup came before we went to
sleep, etc..

The success=0 wakeup is lots faster than the full wakeup (for obvious
reasons), so when analyzing performance related things, one of the
things I look at is the ratio of wakeup success. If the faster case got
lots of unsuccessful wakeups you know there's probably some (wakeup)
preemption like thing gone wrong with the slower case.

In all those cases its nice to see _that_ a wakeup was attempted and
when it was, even if it was unsuccessful.