lkml.org 
[lkml]   [2022]   [Oct]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] perf test: Fix test_arm_coresight.sh failures on Juno
On Thu, Oct 06, 2022 at 04:11:05PM +0100, James Clark wrote:

[...]

> >> Before:
> >>
> >> sudo ./perf test coresight -vvv
> >> ...
> >> Recording trace with system wide mode
> >> Looking at perf.data file for dumping branch samples:
> >> Looking at perf.data file for reporting branch samples:
> >> Looking at perf.data file for instruction samples:
> >> CoreSight system wide testing: FAIL
> >> ...
> >>
> >> After:
> >>
> >> sudo ./perf test coresight -vvv
> >> ...
> >> Recording trace with system wide mode
> >> Looking at perf.data file for dumping branch samples:
> >> Looking at perf.data file for reporting branch samples:
> >> Looking at perf.data file for instruction samples:
> >> CoreSight system wide testing: PASS
> >> ...
> >
> > Since Arm Juno board has zero timestamp for CoreSight, I don't think
> > now arm_cs_etm.sh can really work on it.
> >
> > If we want to pass the test on Juno board, we need to add option
> > "--itrace=Zi1000i" for "perf report" and "perf script"; but seems
> > to me "--itrace=Z..." is not a general case for testing ...
>
> Unfortunately I now think that adding the Z option didn't improve
> anything in Coresight decoding other than removing the warning. I've
> never seen the zero timestamp issue on Juno though. I thought that was
> on some Qualcomm device? I'm not getting the warning on this test anyway.

No, on my Juno-r2 board I can observe the timestamp is always zero
from CoreSight trace data, this is why everytime I must use
"--itrace=Zi1000i" for reporting results.

> The problem is that timeless mode assumes per thread mode, and in per
> thread mode there is a separate buffer per thread, so the Coresight
> channel IDs are ignored. In systemwide mode the channel ID is important
> to know which CPU the trace came from. If this info is thrown away then
> not much works correctly.
>
> I plan to overhaul the whole decoder and remove all the assumptions
> about per-thread and timeless mode. It would be better if they were
> completely separate concepts.

Okay, good to know this.

[...]

> > So here I am suspect that changing to "--itrace=i20i" can allow the test
> > to pass on Juno board. Could you confirm for this?
>
> On Juno:
>
> ./perf record -e cs_etm// -a -- ls
>
> With interval 20, 23 instruction samples are generated:
>
> ./perf report --stdio --itrace=i20i | egrep " +[0-9]+\.[0-9]+% +perf "
> | wc -l
>
> 23
>
> With interval 1000, 0 are generated:
>
> ./perf report --stdio --itrace=i1000i | egrep " +[0-9]+\.[0-9]+% +perf
> " | wc -l
>
> Error:
> The perf.data data has no samples!
> 0

Thanks for confirmation. It's a bit weird that your Juno board doesn't
produce all zeros for timestamp packets.

> I think the issue is that ls is quite quick to run, so not much trace is
> generated for Perf. And it just depends on the scheduling which is
> slightly different on Juno. I don't think it's a bug. On N1SDP there are
> only 134 samples generated with i1000i, so it could probably end up with
> a random run generating 0 there too.

Agreed, changing to smaller interval makes sense for me.

Reviewed-by: Leo Yan <leo.yan@linaro.org>

Thanks,
Leo

\
 
 \ /
  Last update: 2022-10-10 09:45    [W:0.054 / U:0.508 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site