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

Groups > linux.kernel > #1411103 > unrolled thread

[RFC PATCH 0/4] Integration of function trace with System Trace IP blocks

Back to article view | Back to linux.kernel

Contents

  [RFC PATCH 0/4] Integration of function trace with System Trace IP blocks Chunyan Zhang <zhang.chunyan@linaro.org> - 2016-06-01 13:20 +0200
    [RFC PATCH 3/4] trace: Duplicate the output of the function trace logs to STM Chunyan Zhang <zhang.chunyan@linaro.org> - 2016-06-01 13:20 +0200
      Re: [RFC PATCH 3/4] trace: Duplicate the output of the function trace logs to STM Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2016-06-07 12:10 +0200
        Re: [RFC PATCH 3/4] trace: Duplicate the output of the function trace  logs to STM Chunyan Zhang <zhang.chunyan@linaro.org> - 2016-06-08 13:10 +0200
    Re: [RFC PATCH 0/4] Integration of function trace with System Trace IP blocks Alexander Shishkin <alexander.shishkin@linux.intel.com> - 2016-06-07 13:00 +0200
      Re: [RFC PATCH 0/4] Integration of function trace with System Trace  IP blocks Chunyan Zhang <zhang.chunyan@linaro.org> - 2016-06-08 13:10 +0200

#1411103 — [RFC PATCH 0/4] Integration of function trace with System Trace IP blocks

IP blocks allowing a variety of trace sources to log debugging
information to a pre-defined area have been introduced on a couple of
architecture [1][2]. These system trace blocks (also known as STM)
typically follow the MIPI STPv2 protocol [3] and provide a system wide
logging facility to any device, running a kernel or not, with access
to the block's log entry port(s).  Since each trace message has a
timestamp, it is possible to correlate events happening in the entire
system rather than being confined to the logging facility of a single
entity.

This patchset is an RFC aimed at generating ideas on the best way to
use STM IP blocks to collect function tracing information produced by
Ftrace.  That way logging information generated by the function trace
subsystem and gathered in the coresight sink can be used in conjunction
with trace data from other board components, also collected in the same
trace sink.  This example is using ARM coresight STM but the same would
apply to any architecture wishing to do the same.

Comments and advice would be greatly appreciated.


Thanks,
Chunyan

[1]. https://lwn.net/Articles/674746/
[2]. http://lxr.free-electrons.com/source/drivers/hwtracing/intel_th/
[3]. http://mipi.org/specifications/debug#STP
[4]. http://lxr.free-electrons.com/source/include/linux/stm.h

Chunyan Zhang (4):
  STM Ftrace: Adding generic buffer interface driver
  trace: Introduce an output interface from ftrace to STM
  trace: Duplicate the output of the function trace logs to STM
  stm: Mark the functions of writing buffer with notrace

 drivers/hwtracing/coresight/coresight-stm.c |  2 +-
 drivers/hwtracing/intel_th/sth.c            | 11 +++---
 drivers/hwtracing/stm/Kconfig               |  9 +++++
 drivers/hwtracing/stm/Makefile              |  2 ++
 drivers/hwtracing/stm/core.c                |  7 ++--
 drivers/hwtracing/stm/dummy_stm.c           |  2 +-
 drivers/hwtracing/stm/stm_ftrace.c          | 54 +++++++++++++++++++++++++++++
 include/linux/stm.h                         |  4 +--
 kernel/trace/Makefile                       |  1 +
 kernel/trace/trace.c                        |  5 ++-
 kernel/trace/trace_output_stm.c             | 27 +++++++++++++++
 kernel/trace/trace_output_stm.h             | 14 ++++++++
 12 files changed, 126 insertions(+), 12 deletions(-)
 create mode 100644 drivers/hwtracing/stm/stm_ftrace.c
 create mode 100644 kernel/trace/trace_output_stm.c
 create mode 100644 kernel/trace/trace_output_stm.h

-- 
1.9.1

[toc] | [next] | [standalone]

#1411105 — [RFC PATCH 3/4] trace: Duplicate the output of the function trace logs to STM

This patch adds an output from Ftrace to STM.  That being said,
Function trace messages would also be duplicated to STM buffer when
being stored into ring buffer.

Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
---
 kernel/trace/trace.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 8a4bd6b..d613053 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -44,6 +44,7 @@
 
 #include "trace.h"
 #include "trace_output.h"
+#include "trace_output_stm.h"
 
 /*
  * On boot up, the ring buffer is set to the minimum size, so that
@@ -1884,8 +1885,10 @@ trace_function(struct trace_array *tr,
 	entry->ip			= ip;
 	entry->parent_ip		= parent_ip;
 
-	if (!call_filter_check_discard(call, entry, buffer, event))
+	if (!call_filter_check_discard(call, entry, buffer, event)) {
 		__buffer_unlock_commit(buffer, event);
+		ftrace_stm_func(ip, parent_ip);
+	}
 }
 
 #ifdef CONFIG_STACKTRACE
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

#1415957 — Re: [RFC PATCH 3/4] trace: Duplicate the output of the function trace logs to STM

Chunyan Zhang <zhang.chunyan@linaro.org> writes:

> This patch adds an output from Ftrace to STM.

But does it?

> That being said,
> Function trace messages would also be duplicated to STM buffer when
> being stored into ring buffer.

Not sure what you mean here. What's "STM buffer"?

>
> Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
> ---
>  kernel/trace/trace.c | 5 ++++-
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
> index 8a4bd6b..d613053 100644
> --- a/kernel/trace/trace.c
> +++ b/kernel/trace/trace.c
> @@ -44,6 +44,7 @@
>  
>  #include "trace.h"
>  #include "trace_output.h"
> +#include "trace_output_stm.h"
>  
>  /*
>   * On boot up, the ring buffer is set to the minimum size, so that
> @@ -1884,8 +1885,10 @@ trace_function(struct trace_array *tr,
>  	entry->ip			= ip;
>  	entry->parent_ip		= parent_ip;
>  
> -	if (!call_filter_check_discard(call, entry, buffer, event))
> +	if (!call_filter_check_discard(call, entry, buffer, event)) {
>  		__buffer_unlock_commit(buffer, event);
> +		ftrace_stm_func(ip, parent_ip);
> +	}

So this logs instruction pointers, not the actual events. Not much is
duplicated like the message suggests, but it also doesn't seem very
useful.

Regards,
--
Alex

[toc] | [prev] | [next] | [standalone]

#1417293 — Re: [RFC PATCH 3/4] trace: Duplicate the output of the function trace logs to STM

On Tue, Jun 7, 2016 at 6:00 PM, Alexander Shishkin
<alexander.shishkin@linux.intel.com> wrote:
> Chunyan Zhang <zhang.chunyan@linaro.org> writes:
>
>> This patch adds an output from Ftrace to STM.
>
> But does it?
>
>> That being said,
>> Function trace messages would also be duplicated to STM buffer when
>> being stored into ring buffer.
>
> Not sure what you mean here. What's "STM buffer"?

Sorry if this is ambiguously expression, I mean the buffer which
stores the trace data from STM, such as ETB/TMC for CoreSight.

>
>>
>> Signed-off-by: Chunyan Zhang <zhang.chunyan@linaro.org>
>> ---
>>  kernel/trace/trace.c | 5 ++++-
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
>> index 8a4bd6b..d613053 100644
>> --- a/kernel/trace/trace.c
>> +++ b/kernel/trace/trace.c
>> @@ -44,6 +44,7 @@
>>
>>  #include "trace.h"
>>  #include "trace_output.h"
>> +#include "trace_output_stm.h"
>>
>>  /*
>>   * On boot up, the ring buffer is set to the minimum size, so that
>> @@ -1884,8 +1885,10 @@ trace_function(struct trace_array *tr,
>>       entry->ip                       = ip;
>>       entry->parent_ip                = parent_ip;
>>
>> -     if (!call_filter_check_discard(call, entry, buffer, event))
>> +     if (!call_filter_check_discard(call, entry, buffer, event)) {
>>               __buffer_unlock_commit(buffer, event);
>> +             ftrace_stm_func(ip, parent_ip);
>> +     }
>
> So this logs instruction pointers, not the actual events. Not much is
> duplicated like the message suggests, but it also doesn't seem very
> useful.

Yes, only knowing function pointers may not be very useful, if doing
in this way is acceptable I intend to add more interfaces to export
more information to STM in the feature, I will appreciate if you can
tell me what information you think is _absolutely_ necessary.

Thanks,
Chunyan

>
> Regards,
> --
> Alex

[toc] | [prev] | [next] | [standalone]

#1415989

Chunyan Zhang <zhang.chunyan@linaro.org> writes:

> This patchset is an RFC aimed at generating ideas on the best way to
> use STM IP blocks to collect function tracing information produced by
> Ftrace.  That way logging information generated by the function trace
> subsystem and gathered in the coresight sink can be used in conjunction
> with trace data from other board components, also collected in the same
> trace sink.  This example is using ARM coresight STM but the same would
> apply to any architecture wishing to do the same.

I'd say, traces are only useful if you can make sense of them. This
patchset basically sends out addresses, which only makes sense if the
decoding side has vmlinux of the kernel under tracing. But even if they
do, other context information is still missing, such as the cpu ids of
these events, without which you can't really tell what's been going
on. You can, of course, still use this data for coverage analysis, but
there are easier ways of doing that already.

So I'd say that first you need to export at least as much as is written
to the ftrace ring buffer. And perhaps, to avoid inventing yet another
binary protocol, it would have to be exactly what is written to the
ftrace ring buffer.

Then you need to think whether you want to export binary ftrace data or
ascii-formatted strings:
  * binary data is way less overhead;
  * ascii data is self-contained;
  * binary data requires the exact running kernel's binaries to decode
  and the ability to read them (say, if you wanted to read the traces on
  some other OS that doesn't have native support for ELF binaries);
  every time you recompile the target kernel, you'll have to copy it
  over to the debug host;
  * ascii data can be looked at independently.

That's off the top of my head.

Regards,
--
Alex

[toc] | [prev] | [next] | [standalone]

#1417286 — Re: [RFC PATCH 0/4] Integration of function trace with System Trace IP blocks

Hi Alex,

Thanks for your comments on every patch of this serial.

On Tue, Jun 7, 2016 at 6:50 PM, Alexander Shishkin
<alexander.shishkin@linux.intel.com> wrote:
> Chunyan Zhang <zhang.chunyan@linaro.org> writes:
>
>> This patchset is an RFC aimed at generating ideas on the best way to
>> use STM IP blocks to collect function tracing information produced by
>> Ftrace.  That way logging information generated by the function trace
>> subsystem and gathered in the coresight sink can be used in conjunction
>> with trace data from other board components, also collected in the same
>> trace sink.  This example is using ARM coresight STM but the same would
>> apply to any architecture wishing to do the same.
>
> I'd say, traces are only useful if you can make sense of them. This
> patchset basically sends out addresses, which only makes sense if the
> decoding side has vmlinux of the kernel under tracing. But even if they

I guess it shouldn't hard to be implemented.

> do, other context information is still missing, such as the cpu ids of

On ARM Platform, STM master IDs are related with CPU cores, so long as
we know which master the traces come from, we know the CPU id it
happened on.  Doesn't Intel STM have this kind of similar mechanism?

> these events, without which you can't really tell what's been going
> on. You can, of course, still use this data for coverage analysis, but
> there are easier ways of doing that already.
>
> So I'd say that first you need to export at least as much as is written
> to the ftrace ring buffer. And perhaps, to avoid inventing yet another
> binary protocol, it would have to be exactly what is written to the
> ftrace ring buffer.

In order to minimize overhead introduced by exporting message to STM,
we perhaps cannot record as much information as is exported to Ftrace
ring buffer.  The pointers of function and its parent function may not
be enough though, we can see what else is required.  But we may not
need such as timestamp, cpuid, since CoreSight has its own timestamp
and I guess Intel STM is the same;  About the cpuid for Intel STM, can
we have some way to know that, for example using different channel to
identify that?

>
> Then you need to think whether you want to export binary ftrace data or
> ascii-formatted strings:
>   * binary data is way less overhead;

Right, that's why I changed to this way, I sent out one patchset
before in which ascii-formatted strings was recorded to STM, but
adding that process introduced too much overhead to be accepted for
Ftrace subsystem, I dropped that solution.

>   * ascii data is self-contained;
>   * binary data requires the exact running kernel's binaries to decode
>   and the ability to read them (say, if you wanted to read the traces on
>   some other OS that doesn't have native support for ELF binaries);
>   every time you recompile the target kernel, you'll have to copy it
>   over to the debug host;

Yes. I think if we want to use this feature, we have to make vmlinux
as a part of the decoding library.

>   * ascii data can be looked at independently.

Above all are my superficial opinions, please correct me if I'm
missing something, and will appreciate if you can give more
suggestions/opinions.

Thanks,
Chunyan

>
> That's off the top of my head.
>
> Regards,
> --
> Alex

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web