[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
[off-list ref] wrote:

Chunyan Zhang [off-list ref] writes:

quoted

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