From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932303AbbFFMCm (ORCPT <rfc822;w@1wt.eu>);
	Sat, 6 Jun 2015 08:02:42 -0400
Received: from bombadil.infradead.org ([198.137.202.9]:54965 "EHLO
	bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S932237AbbFFMCc convert rfc822-to-8bit (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sat, 6 Jun 2015 08:02:32 -0400
Message-ID: <1433592142.1495.22.camel@twins>
Subject: Re: [RFC PATCH] sched: Fix sched_wakeup tracepoint
From: Peter Zijlstra <peterz@infradead.org>
To: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
Cc: linux-kernel@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>,
        Ingo Molnar <mingo@kernel.org>, rostedt <rostedt@goodmis.org>,
        Francis Giraldeau <francis.giraldeau@gmail.com>
Date: Sat, 06 Jun 2015 14:02:22 +0200
In-Reply-To: <600031664.4911.1433510581646.JavaMail.zimbra@efficios.com>
References: <1433504509-17013-1-git-send-email-mathieu.desnoyers@efficios.com>
	 <20150605120909.GG19282@twins.programming.kicks-ass.net>
	 <479621151.4836.1433507522491.JavaMail.zimbra@efficios.com>
	 <1433508695.1495.16.camel@twins>
	 <600031664.4911.1433510581646.JavaMail.zimbra@efficios.com>
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7BIT
X-Mailer: Evolution 3.10.4-0ubuntu2 
Mime-Version: 1.0
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Fri, 2015-06-05 at 13:23 +0000, Mathieu Desnoyers wrote:
> OK, so considering the definition naming feedback you provided, we
> may need a 3 tracepoint if we want to calculate both wakeup latency
> and scheduling latency (naming ofc open to discussion):
> 
> 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.

I would propose:

	sched_waking: upon calling try_to_wake_up() as soon as we know we need
to change state; guaranteed to be called from the context doing the
wakeup.

	sched_woken: the wakeup is complete (task is runnable, any delay
between this and actually getting on a cpu is down to the scheduler).

	sched_switch: when switching from task @prev to @next.

This means abandoning trace_sched_wakeup(); which might be a problem,
which is why I bloody hate tracepoints :-(

> We can then calculate wakeup latency as
> 
>   time@sched_activate - time@sched_wakeup
> 
> And scheduling latency as
> 
>   time@sched_switch - time@sched_activate
> 
> In the case of critical path analysis, we don't care about this
> level of granularity. What we care about is is sum of the two,
> which we can express as:
> 
>   time@sched_switch - time@sched_wakeup
> 
> Is there an officially blessed name for this ?

No idea.