Messages in this thread | | | Date | Tue, 9 Jun 2015 05:53:01 +0000 (UTC) | From | Mathieu Desnoyers <> | Subject | Re: [RFC PATCH] sched: Fix sched_wakeup tracepoint |
| |
----- 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
| |