Re: [PATCH] perf test: Fix test_arm_coresight.sh failures on Juno

[Leo Yan]

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@xxxxxxxxxx>

Thanks,
Leo