Messages in this thread | | | Date | Thu, 15 Apr 2021 22:33:29 +0800 | From | Leo Yan <> | Subject | Re: [PATCH 2/2] perf cs-etm: Set time on synthesised samples to preserve ordering |
| |
Hi James,
On Thu, Apr 15, 2021 at 03:51:46PM +0300, James Clark wrote:
[...]
> > For the orignal perf data file with "--per-thread" option, the decoder > > runs into the condition for "etm->timeless_decoding"; and it doesn't > > contain ETM timestamp. > > > > Afterwards, the injected perf data file also misses ETM timestamp and > > hit the condition "etm->timeless_decoding". > > > > So I am confusing why the original perf data can be processed properly > > but fails to handle the injected perf data file. > > Hi Leo, > > My patch only deals with per-cpu mode. With per-thread mode everything is already working > because _none_ of the events have timestamps because they are not enabled by default: > > /* In per-cpu case, always need the time of mmap events etc */ > if (!perf_cpu_map__empty(cpus)) > evsel__set_sample_bit(tracking_evsel, TIME); > > When none of the events have timestamps, I think perf doesn't use the ordering code in > ordered-events.c. So when the inject file is opened, the events are read in file order.
The explination makes sense to me. One thinking: if the original file doesn't use the ordered event, is it possible for the injected file to not use the ordered event as well?
Could you confirm Intel-pt can work well for per-cpu mode for inject file?
> So it's not really about --per-thread vs per-cpu mode, it's actually about whether > PERF_SAMPLE_TIME is set, which is set as a by-product of per-cpu mode. > > I hope I understood your question properly.
Thanks for info, sorry if I miss any info you have elaborated.
Leo
| |