Hi Alex, Thanks for your comments on every patch of this serial.
On Tue, Jun 7, 2016 at 6:50 PM, Alexander Shishkin <[email protected]> wrote: > Chunyan Zhang <[email protected]> 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
