[PATCH 2/2] perf cs-etm: Set time on synthesised samples to preserve ordering
Leo Yan
leo.yan at linaro.org
Thu Apr 15 15:33:29 BST 2021
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
More information about the linux-arm-kernel
mailing list