Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753648AbdGLTRp (ORCPT ); Wed, 12 Jul 2017 15:17:45 -0400 Received: from mga03.intel.com ([134.134.136.65]:64541 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751075AbdGLTRm (ORCPT ); Wed, 12 Jul 2017 15:17:42 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,351,1496127600"; d="scan'208";a="126404002" Message-ID: <1499887058.3995.28.camel@tzanussi-mobl.amr.corp.intel.com> Subject: Re: [PATCH 00/32] tracing: Inter-event (e.g. latency) support From: Tom Zanussi To: "Joel Fernandes (Google)" Cc: rostedt@goodmis.org, tglx@linutronix.de, mhiramat@kernel.org, namhyung@kernel.org, vedang.patel@intel.com, Linux Kernel Mailing List , linux-rt-users@vger.kernel.org Date: Wed, 12 Jul 2017 14:17:38 -0500 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.10.4 (3.10.4-4.fc20) Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1917 Lines: 50 Hi Joel, Sorry for the delayed reply, was out for the holidays.. On Sat, 2017-07-01 at 00:01 -0700, Joel Fernandes (Google) wrote: > Hi Tom, > Nice series and nice ELC talk as well. Thanks. > > On Mon, Jun 26, 2017 at 3:49 PM, Tom Zanussi > wrote: > > This patchset adds support for 'inter-event' quantities to the trace > > event subsystem. The most important example of inter-event quantities > > are latencies, or the time differences between two events. > > I tried your patches out and they are working fine for me. I will test > them out more. > > I think for the wakeup latency in your examples, its better / more > accurate to use sched_waking instead of sched_wakeup tracepoint? [1] > Yeah, makes sense - thanks for pointing it out. > Also, one other comment I had is, it would be nice to suppress the > output of individual trace events that are part of the synthetic event > into the trace buffer. Otherwise I feel the value of it is slightly > diminished - because one can simply post-process the individual > non-synthetic trace events themselves to get wake up latencies which > the synthetic events is trying to calculate in the first place. > Inorder to conserve space, if a user doesn't care about individual > events, and just the synthetic events then the individual ones > shouldn't be written to the trace buffer IMO. > Yes, you're right, this is also something I need to fix. I added a flag to avoid discards, but this has the effect of, well, avoiding discards, so unwanted events appear in the trace buffer. Also, regardless, any trigger that exists simply to provide input to a synthetic event should be filtered out, regardless of the enable state. I'll have to think about a better way do handle all this... Thanks, Tom > -Joel > > [1] commit fbd705a0c6184580d0e2fbcbd47a37b6e5822511 (sched: Introduce > the 'trace_sched_waking' tracepoint)