On 03/06/2026 3:36 pm, Leo Yan wrote:
On Tue, Jun 02, 2026 at 03:26:50PM +0100, James Clark wrote:
[...]
+# Use exit snapshot to record 2M of trace to make about 80MB of raw dump data. +echo "Recording..." +perf record -e cs_etm/timestamp=0/u -m,2M -Se -o "$tmpdir/data" -- \
- perf test -w brstack 20000 > /dev/null 2>&1
...
+size=$(stat -c%s "$tmpdir/rawdump") +if [ $size -gt $((50 * 1024 * 1024)) ]; then
- echo "PASS: Raw dump file is larger than 50MB"
- cleanup
- exit 0
+fi
I am not sure how we can map 2MiB trace data to 50MiB+ raw dump. This
Why not? Decoding it is roughly equal to decompressing it, and with that amount of trace the small differences in compressibility average out and you do get the same amount every time. I think if we got less than half the amount expected then it would be worth investigating.
is not to verify perf stuffs but just expect how verbose output from decoder.
Can we simply verify the trace data is ~2MiB with the command:
perf report -D | grep ". ... CoreSight .* Trace data: size .* bytes"
We might relax the check as the trace size >= 90% * 2MiB
Thanks, Leo
That would work, but that wouldn't be as thorough. The first thing it prints is " CoreSight .* Trace data: size .* bytes". If it stops working half way through or prints nothing then the test will still pass.
The reason I wanted to add a stress test is because all of the other tests have been reduced to just a few kb of trace so we have nothing that opens a file with a more reasonable amount of data.
I suppose with your suggestion we'd still check the exit code, but that's about it.