Hi Al,
On Thu, Dec 10, 2020 at 11:23:20AM +0000, Al Grant wrote:
[...]
b) Even if the arch timer is not running the coresight timestamp, or the coresight timestamp is not enabled, will it be correct to associate the arch timestamp in the AUX record with that in the MMAP2 records, and therefore have all the information needed for correct decode of the block of trace in the AUXTRACE record associated with the AUX record?
The timestamps in the AUX record is a kernel timestamp, so it is correct to associate it with the timestamps in the MMAP records. The only risk is that the AUX buffer segment may contain some trace from any time prior to when the AUX record was generated, including times from before the MMAP occurred. At worst, you could have a situation like this:
- start trace collection into a buffer
- client unloads abc.so (at an address)
- client loads xyz.so into the same address range, generating MMAP
- collect trace into an AUX segment, generating AUX
In the trace there may be references to a given address which may be from either abc.so or xyz.so, and the timestamps will not resolve this. This is quite unlikely, but it would be more likely if trace was being collected at a relatively slow rate, and/or with filtering.
Yeah, this is a good example for why we need the timestamp to achieve more accurate output result.
There may be similar issues with JIT, if you're using jitdump files to track when code is dynamically generated.
For the JIT, it's a different topic (and it is difficult to resolve). Perf framework provides TEXT_POKE event for instruction alternation; for eBPF file, perf tool can use the BTF for symbol parsing.
To do any better you'd need the timestamps embedded within the ETM stream itself, and convert those to kernel time, which we currently have no mechanism for.
Thanks for explaination.
Leo