Messages in this thread | | | Subject | Re: [RFC PATCH] sched: Fix sched_wakeup tracepoint | From | Peter Zijlstra <> | Date | Fri, 05 Jun 2015 14:46:46 +0200 |
| |
On Fri, 2015-06-05 at 14:32 +0200, Thomas Gleixner wrote: > On Fri, 5 Jun 2015, Peter Zijlstra wrote: > > On Fri, Jun 05, 2015 at 01:41:49PM +0200, Mathieu Desnoyers wrote: > > > Commit 317f394160e9 "sched: Move the second half of ttwu() to the remote cpu" > > > moves ttwu_do_wakeup() to an IPI handler context on the remote CPU for > > > remote wakeups. This commit appeared upstream in Linux v3.0. > > > > > > Unfortunately, ttwu_do_wakeup() happens to contain the "sched_wakeup" > > > tracepoint. Analyzing wakup latencies depends on getting the wakeup > > > chain right: which process is the waker, which is the wakee. Moving this > > > instrumention outside of the waker context prevents trace analysis tools > > > from getting the waker pid, either through "current" in the tracepoint > > > probe, or by deducing it using other scheduler events based on the CPU > > > executing the tracepoint. > > > > > > Another side-effect of moving this instrumentation to the scheduler ipi > > > is that the delay during which the wakeup is sitting in the pending > > > queue is not accounted for when calculating wakeup latency. > > > > > > Therefore, move the sched_wakeup instrumentation back to the waker > > > context to fix those two shortcomings. > > > > What do you consider wakeup-latency? I don't see how moving the > > tracepoint into the caller will magically account the queue time. > > Well, the point of wakeup is when the wakee calls wakeup. If the trace > point is in the IPI then you account the time between the wakeup and > the actuall handling in the IPI to the wakee instead of accounting it > to the time between wakeup and sched switch.
My point exactly, wake->schedule is what we call the scheduling latency, not the wake latency, which would be from 'event' to the task being runnable.
| |