On Thu, 5 Mar 2020 at 08:30, Mathieu Poirier mathieu.poirier@linaro.org wrote:
On Thu, 5 Mar 2020 at 03:28, Andrea Brunato Andrea.Brunato@arm.com wrote:
Thank you Leo, this is really valuable! I'm going to update my kernel version to the latest one - hopefully I'll manage to do this as soon as possible
As I'm trying different configurations, I've got a very interesting result:
$ taskset -c 0 perf record --per-thread -e cs_etm/sinkid=0xa6509eae/u ~/afdo/coremark/coremark/coremark.exe 0x3415 0x3415 0x66 0 7 1 2000 > run2.log
Once again examples include "sinkid=0xa6509eae", a syntax that was __never__ supported in any version of the code that was published. Since there is now way for me to know where that code comes from, the platform it is running on or the modifications that were done to it, I will not answer any question or follow email threads where that syntax is used.
After going back to the email thread on this topic I realise that I missed the reply where you did answer my question on the "sinkid" parameter. Missing that information prompted the above rebuke, something I hereby apologise for.
The "sinkid" parameter is published to be conformant to the perf framework and avoid problems with automated kernel interface testers. That being said we always encourage people to use the documented syntax. If that returns an error something else is wrong and should be fixed first.
Regards, Mathieu
Thanks, Mathieu
[ perf record: Woken up 28 times to write data ] Warning: AUX data lost 25 times out of 27!
[ perf record: Captured and wrote 3.323 MB perf.data ]
While instead, when NOT pinning the program to a specific core
$ perf record --per-thread -e cs_etm/sinkid=0xa6509eae/u ~/afdo/coremark/coremark/coremark.exe 0x3415 0x3415 0x66 0 7 1 2000 > run2.log [ perf record: Woken up 4 times to write data ] Warning: AUX data lost 4 times out of 4!
[ perf record: Captured and wrote 0.502 MB perf.data ]
While the information lost rate is still high, the `time` AUX data has been lost is very different: 27 vs 4 Also the reported perf.data file is way bigger when pinning the task to a specific core.
Interestingly enough, when instead tracing a short-lived program such as `ls`, there is no difference in the perf.data reported.
Is anybody aware of any specific part in the code base whose behavior may change according to the traced program being rescheduled to another core? Any idea/suggestion is highly appreciated
Thanks, Andrea
From: Leo Yan leo.yan@linaro.org Sent: 05 March 2020 01:55 To: Andrea Brunato Andrea.Brunato@arm.com Cc: Mike Leach mike.leach@linaro.org; Mathieu Poirier mathieu.poirier@linaro.org; guermazi.zied@gmail.com guermazi.zied@gmail.com; coresight@lists.linaro.org coresight@lists.linaro.org Subject: Re: perf record cs_etm: data lost
Hi Andrea,
On Wed, Mar 04, 2020 at 03:45:59PM +0000, Andrea Brunato wrote:
Thank you Mike - I'm getting a way better understanding of the whole system.
Sorry for sharing a wrong command, unfortunately on 5.5.0-rc7 I see the same error persisting when running:
$ perf record --per-thread -e cs_etm/@tmc_etr0/u -- ls failed to set sink "" on event cs_etm/@tmc_etr0/u with 21 (Is a directory)
I'm using perf built as an Arm binary against the same kernel source code while linked against openCSD.
Just want to remind, please check if these two patches [1][2] have been merged into your local code base, otherwise, before we found the regression for inputting sink name in perf command.
Thanks, Leo
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i... [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i... 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.