From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932460AbbFEMhG (ORCPT ); Fri, 5 Jun 2015 08:37:06 -0400 Received: from mail.efficios.com ([78.47.125.74]:54084 "EHLO mail.efficios.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752505AbbFEMhE (ORCPT ); Fri, 5 Jun 2015 08:37:04 -0400 Date: Fri, 5 Jun 2015 12:36:54 +0000 (UTC) From: Mathieu Desnoyers To: Thomas Gleixner Cc: Peter Zijlstra , linux-kernel@vger.kernel.org, Ingo Molnar , rostedt , "Giraldeau, Francis" Message-ID: <216035439.4869.1433507814799.JavaMail.zimbra@efficios.com> In-Reply-To: References: <1433504509-17013-1-git-send-email-mathieu.desnoyers@efficios.com> <20150605120909.GG19282@twins.programming.kicks-ass.net> Subject: Re: [RFC PATCH] sched: Fix sched_wakeup tracepoint MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [78.47.125.74] X-Mailer: Zimbra 8.6.0_GA_1153 (ZimbraWebClient - FF38 (Linux)/8.6.0_GA_1153) Thread-Topic: sched: Fix sched_wakeup tracepoint Thread-Index: HA7s2cTPROsKZAiR1t8Gx1RMhL//dA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ----- On Jun 5, 2015, at 2:32 PM, Thomas Gleixner tglx@linutronix.de 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 ^ I think you actually mean "when the waker calls wakeup". > 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. > Thanks, Mathieu > Thanks, > > tglx -- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com