Hi, Is this a linux distribution or an android running on a linux kernel for android? I'm running a linux distribution, Debian Buster What is "sinkid=0xa6509eae" ? It's the sinkid corresponding to tmc_etr0. When casting the perf command using @tmc_etr0 unfortunately I'm displayed the following error:
$ perf record --per-thread -e cs_etm/@tmc_etr/u -- ls
failed to set sink "" on event cs_etm/@tmc_etr/u with 21 (Is a directory)
so I found myself forced to manually specify the identifier. I think this problem has been solved in the latest kernel versions but I still have to double check.
My CoreSight subsystem is the following:
$ ls /sys/bus/coresight/devices/
etm0 etm1 etm2 etm3 etm4 etm5 etm6 etm7 funnel0 funnel1 funnel2 funnel3 funnel4 replicator0 stm0 tmc_etf0 tmc_etr0
$ grep . /sys/devices/cs_etm/sinks/* /sys/devices/cs_etm/sinks/tmc_etf0:0x97979549 /sys/devices/cs_etm/sinks/tmc_etr0:0xa6509eae
To allow the "--mmap-pages" to work with big buffer, the sink needs to directly output trace data to DDR, you also need to take care what's the buffer mode you are using (flat, sg, CATU).
Thanks for the suggestion! Is there a way for me to enforce this? Is it possible to check out how much data I'm losing/overwriting? Do you know what is the best buffer mode for avoiding losing data? How can I switch between a buffer mode and another one? Is `--per-thread` the best way to trace a single-threaded workload?
Thanks everybody for the interest on this! Andrea ________________________________ From: Mathieu Poirier mathieu.poirier@linaro.org Sent: 04 March 2020 02:43 To: leo.yan@linaro.org leo.yan@linaro.org Cc: Andrea Brunato Andrea.Brunato@arm.com; coresight@lists.linaro.org coresight@lists.linaro.org Subject: Re: perf record cs_etm: data lost
On Tue, 3 Mar 2020 at 18:54, Leo Yan leo.yan@linaro.org wrote:
Hi Andrea,
On Tue, Mar 03, 2020 at 11:23:29AM -0700, Mathieu Poirier wrote:
Hi Andrea,
On Tue, 3 Mar 2020 at 09:34, Andrea Brunato Andrea.Brunato@arm.com wrote:
Good afternoon,
When using perf to record a simple benchmark I see the following warning:
$ perf record --per-thread -e cs_etm/sinkid=0xa6509eae/u ~/afdo/coremark/coremark/coremark.exe 0x3415 0x3415 0x66 0 7 1 2000 > run2.log
What is "sinkid=0xa6509eae" ?
Sink might be ETF/ETR/ETB, I think this is why Mathieu asked the meaning for 'sinkid', which we don't which sink you are using.
[ perf record: Woken up 6 times to write data ] Warning: AUX data lost 6 times out of 6!
[ perf record: Captured and wrote 0.378 MB perf.data ]
This is on DB845c (https://www.96boards.org/product/rb3-platform/), kernel 5.5.0-rc7.
It looks like perf is losing data and the reported perf.data file is very tiny, given that the application runs for several seconds. Does anybody have any idea about what it may be causing this?
Just give some info based on my understanding.
For the log "AUX data lost 6 times out of 6!", since you are using per-thread mode, so every time when the task switching out, the trace data in the sink will be read out and save into aux buffer. But usually the sink's buffer is not big (maximum to MBs), so it's easily to overwrite the hardware's cycle buffer and the previous trace data will be lost. For this reason, it reports "AUX data lost".
I've tried adding --mmap-pages=32K,64K to the command for increasing the buffer size, but it's not actually solving the problem
If it's the overflow in the hardware buffer in SRAM, "--mmap-pages" option doesn't work, since it only enlarges aux buffer page size but cannot change the SRAM size in CoreSight.
To allow the "--mmap-pages" to work with big buffer, the sink needs to directly output trace data to DDR, you also need to take care what's the buffer mode you are using (flat, sg, CATU).
Everything Leo said above is accurate.
Thanks, Leo
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.