Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1179770

Re: [RFC PATCH v3 4/4] trace: Trace log handler for logging into STM blocks

From Chunyan Zhang <zhang.chunyan@linaro.org>
Newsgroups linux.kernel
Subject Re: [RFC PATCH v3 4/4] trace: Trace log handler for logging into STM blocks
Date 2015-07-08 15:10 +0200
Message-ID <pJXgU-38d-57@gated-at.bofh.it> (permalink)
References <pJy8N-4of-5@gated-at.bofh.it> <pJy8N-4of-3@gated-at.bofh.it> <pJWNQ-2GX-9@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed, Jul 8, 2015 at 8:31 PM, Peter Zijlstra <peterz@infradead.org> 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/

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC PATCH v3 4/4] trace: Trace log handler for logging into STM blocks Chunyan Zhang <zhang.chunyan@linaro.org> - 2015-07-07 12:20 +0200
  Re: [RFC PATCH v3 4/4] trace: Trace log handler for logging into STM  blocks Peter Zijlstra <peterz@infradead.org> - 2015-07-08 14:40 +0200
    Re: [RFC PATCH v3 4/4] trace: Trace log handler for logging into STM blocks Chunyan Zhang <zhang.chunyan@linaro.org> - 2015-07-08 15:10 +0200
      Re: [RFC PATCH v3 4/4] trace: Trace log handler for logging into STM  blocks Ingo Molnar <mingo@kernel.org> - 2015-07-08 15:30 +0200
    Re: [RFC PATCH v3 4/4] trace: Trace log handler for logging into  STM blocks Steven Rostedt <rostedt@goodmis.org> - 2015-07-08 15:20 +0200
      Re: [RFC PATCH v3 4/4] trace: Trace log handler for logging into STM blocks Chunyan Zhang <zhang.chunyan@linaro.org> - 2015-07-10 11:10 +0200
      Re: [RFC PATCH v3 4/4] trace: Trace log handler for logging into STM blocks Chunyan Zhang <zhang.chunyan@linaro.org> - 2015-07-17 08:00 +0200

csiph-web