Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758625AbbGHNGU (ORCPT ); Wed, 8 Jul 2015 09:06:20 -0400 Received: from mail-wi0-f170.google.com ([209.85.212.170]:38847 "EHLO mail-wi0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1758519AbbGHNGO (ORCPT ); Wed, 8 Jul 2015 09:06:14 -0400 MIME-Version: 1.0 In-Reply-To: <20150708123148.GF12596@twins.programming.kicks-ass.net> References: <20150708123148.GF12596@twins.programming.kicks-ass.net> Date: Wed, 8 Jul 2015 21:06:13 +0800 Message-ID: Subject: Re: [RFC PATCH v3 4/4] trace: Trace log handler for logging into STM blocks From: Chunyan Zhang To: Peter Zijlstra Cc: Steven Rostedt , 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: 1783 Lines: 44 On Wed, Jul 8, 2015 at 8:31 PM, 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? We don't have two copies when we export the trace logs to STM, because the event trace logs what we can see by catting the Ftrace files haven't been generated at that moment. > >> +++ 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. It doesn't actually, you may decide if enable this feature, the trace event will not be slowed if STM_TRACE_EVENT is not selected. But if this feature enabled, it will indeed take more time than without this feature. Best regards, Chunyan > >> } >> /* >> * 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/