lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.11.1506051430470.7723@nanos>
Date:	Fri, 5 Jun 2015 14:32:46 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...nel.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Francis Giraldeau <francis.giraldeau@...il.com>
Subject: Re: [RFC PATCH] sched: Fix sched_wakeup tracepoint

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.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ