Re: [RFC PATCH] sched: Fix sched_wakeup tracepoint

[Mathieu Desnoyers <mathieu.desnoyers@efficios.com>]

----- On Jun 8, 2015, at 8:55 AM, Peter Zijlstra peterz@infradead.org wrote:

> On Fri, 2015-06-05 at 13:23 +0000, Mathieu Desnoyers wrote:
>> sched_wakeup: when try_to_wake_up{,_local} is called in the waker.
>> sched_activate_task: when the wakee is marked runnable.
>> sched_switch: when scheduling actually happens.
>> 
>> We can then calculate wakeup latency as
>> 
>>   time@sched_activate - time@sched_wakeup
> 
> One more thing, I think I would disagree with this. I would suggest
> never to use the 'wakeup' (or 'waking' in my proposal) for timing. I
> would suggest to use your interrupt tracepoint (or whatever else causes
> wakeup to be called for this).

The nice thing about the 'waking' tracepoint is that there is only
one to trace if we care about wakeup latency, and it only executes when
there is an actual wake up performed.

If we do care about more timing precision of the wakeup latency, we might
indeed want to trace both 'waking' and whatever calls it (interrupt, set
of system calls, etc.)

An instrumentation of 'waking' however seems like a good approximation
of the moment where the wakeup is requested by the waker. Especially
if we compute critical path of a computation: then we already account
for process runtime within the waker before the 'woken' event. So we
don't really care about the extra precision that we would get by tracing
the exact syscall entry point.

In all cases we need the wakee PID awakened by 'waking', which is
unavailable unless we add the 'waking' event.

> 
> The wakeup times should be measured in tasktime -- of course, if
> interrupts/preemption are disabled then tasktime == walltime.
> 
> The scheduling bit OTOH always needs to be measured in walltime, and is
> most affected by the presence of other tasks on the system.
> 
> This too is why I'm not sure it makes sense to combine the two into a
> single measurement. They should be measured in different time domains.

That's a very good point! Agreed.

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com