Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753994AbbGJJCN (ORCPT ); Fri, 10 Jul 2015 05:02:13 -0400 Received: from mail-wg0-f42.google.com ([74.125.82.42]:33679 "EHLO mail-wg0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753577AbbGJJCA (ORCPT ); Fri, 10 Jul 2015 05:02:00 -0400 MIME-Version: 1.0 In-Reply-To: <20150708091928.38c7643a@gandalf.local.home> References: <20150708123148.GF12596@twins.programming.kicks-ass.net> <20150708091928.38c7643a@gandalf.local.home> Date: Fri, 10 Jul 2015 17:01:59 +0800 Message-ID: Subject: Re: [RFC PATCH v3 4/4] trace: Trace log handler for logging into STM blocks From: Chunyan Zhang To: Steven Rostedt Cc: Peter Zijlstra , mingo@redhat.com, Mathieu Poirier , Serge Broslavsky , broonie@kernel.org, Alexander Shishkin , Lyra Zhang , "linux-kernel@vger.kernel.org" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2343 Lines: 62 On Wed, Jul 8, 2015 at 9:19 PM, Steven Rostedt wrote: > On Wed, 8 Jul 2015 14:31:48 +0200 > Peter Zijlstra wrote: > >> On Tue, Jul 07, 2015 at 06:10:43PM +0800, Chunyan Zhang wrote: >> > Add the function 'trace_event_stm_output_##call' for printing events >> > trace log into STM blocks. >> > >> > This patch also adds a function call at where the events have been >> > committed to ring buffer to export the trace event information to >> > STM blocks. >> >> So then you have two copies of the data, why that? Would a scheme were >> data either goes to the STM or the regular buffer not make much more >> sense? >> >> > +++ b/include/trace/perf.h >> > @@ -175,6 +175,7 @@ trace_event_raw_event_##call(void *__data, proto) \ >> > { assign; } \ >> > \ >> > trace_event_buffer_commit(&fbuffer); \ >> > + trace_event_stm_log(&fbuffer); \ >> >> This makes every trace event slower. > > Of course this could use a jump label. > > But I agree, I think a switch to which buffer it should be sent to is > better. I could come up with a way to make the buffer more generic, and > have it switch between where the event is recorded. Thanks, Steve. It cannot be better if there will be a way to meet the requirements both of Trace event and STM. I also don't want to slow down the trace original speed after enable this feature. But I didn't find any way to achieve this ideal effect. This is just why I sent out this RFCs. And I'd also like to explain a fact about STM, which would likely need only a string of trace messages directly when the trace events happened because of its architecture. Anyway, everything is possible, let's brainstorm! If you have any question about STM, please let me know. Many thanks, Chunyan > > -- Steve > >> >> > } >> > /* >> > * The ftrace_test_probe is compiled out, it is only here as a build time check > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/