From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Frank Ch. Eigler" Subject: Re: timing information with perf Date: Tue, 17 Nov 2015 08:31:11 -0500 Message-ID: <20151117133111.GF25870@redhat.com> References: <94D0C06D-C3A7-4BD1-9898-124EE0AA923D@netapp.com> <20151117001233.GC11993@kernel.org> <564AA5AE.1020303@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mx1.redhat.com ([209.132.183.28]:46108 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751686AbbKQNbM (ORCPT ); Tue, 17 Nov 2015 08:31:12 -0500 Content-Disposition: inline In-Reply-To: <564AA5AE.1020303@gmail.com> Sender: linux-perf-users-owner@vger.kernel.org List-ID: To: David Ahern Cc: Arnaldo Carvalho de Melo , "Kornievskaia, Olga" , "linux-perf-users@vger.kernel.org" Hi - > >> global s, t% > >> probe kernel.trace("foobar_enter") { > >> t[tid()]=gettimeofday_us() > >> } > >> probe kernel.trace("foobar_exit") { > >> if (tid() in t) { s <<< gettimeofday_us() - t[tid()] } > >> } > >> probe timer.s(5),end { > >> printf("cumulative average us: %d\n", @avg(s)) > >> } > > [...] > > Interesting solution. How does it scale with CPUs and tasks? It's not a simple question, as there are several factors, but generally fine. systemtap compiles down to native code, so execution is very fast and CPU consumption is not a problem (better than streaming to userspace & processing there). Depending on actual runtime behavior, there may be contention over the t[] array that tracks start-time. systemtap automagically safely locks these for correctness. If contention is high, trylock/timeouts can fail and some probes will be missed. Fail too many and the script will self-terminate. (See [man stap] for some of the related configurables.) There is no contention over the s scalar value tracks elapsed time, since it is implicitly aggregated on a per-cpu basis. That scales without problem. - FChE