On Thu, 16 Aug 2018 at 08:04, Tomasz Nowicki tnowicki@caviumnetworks.com wrote:
Hello Mathieu,
On 14.08.2018 18:08, Mathieu Poirier wrote:
Good morning Tomasz,
On Tue, 14 Aug 2018 at 09:20, tn Tomasz.Nowicki@caviumnetworks.com wrote:
On 13.08.2018 18:47, Mathieu Poirier wrote:
On Wed, 8 Aug 2018 at 01:59, Tomasz Nowicki tnowicki@caviumnetworks.com wrote:
Hi Mathieu,
It's been a while but I am back to Coresight.
Let me remind my setup and the issue I am struggling with now.
Kernel baseline: https://github.com/Linaro/perf-opencsd (perf-opencsd-v4.16) OpenCSD: https://github.com/Linaro/OpenCSD.git (master)
The simplest Coresight components path I used as a start point: ETMv4.1 -> TDR -> FUNNEL -> ETF
As I mentioned TDR is built by Cavium and it was added to aggregate 128 inputs into one output rather than cascading funnels. TDR has its own driver just to keep path connected in Linux Coresight framework.
Here is how I catch some trace data: sudo perf record -C 0 -e cs_etm/@etf0/ --per-thread test_app
The above command line tells perf to trace everything that is happening on CPU0 for as long as "test_app" is executing. In this case the "--per-thread" option is ignored. This is called a CPU-wide trace scenario and is currently not supported for CS (I am currently working on it).
If you want to make sure "test_app" executes on CPU0 and that you trace just that you will need to use the "taskset" utility:
sudo perf record -e cs_etm/@etf0/ --per-thread taskset 0x1 test_app
My apologise, I used 'taskset' part in my command but forgot to mention. Anyway, thank you for clarifying that CPU-wide trace scenario is not supported for now.
An alternative to the above would be to CPU-hotplug out CPU128-255 while you are testing.
Yes, this helped to setup path between source and sink. Finally I am able to decode data with: # sudo perf record -e cs_etm/@etf0/ --per-thread test_app # sudo perf report --stdio
Perfect.
Above command traces everything related to test_app and all I can see in 'perf report' are userspace symbols. Is it possible to trace kernel side? I have tried to narrow down data using '-e cs_etm/@etf0/k' filter but got nothing in 'perf report'.
The ETF buffer is a pretty small one. As such it may be wrapping around and all you get is the user space part. Do you have an ETR on the platform? If so I suggest to download the latest coresight next branch [1] and try with a bigger buffer.
Now I am trying to see exactly the path a processor took through the code according to these instructions: https://github.com/Linaro/OpenCSD/blob/master/HOWTO.md#trace-decoding-with-p... However, on perf-opencsd 'perf-opencsd-v4.16' branch there is no 'cs-trace-disasm.py' script. Are you planning to add this script to mainline kernel or this was just for development purpose?
That script was provided to show what can be done with the results and was never intended to be used by a broad audience. At one point it became too difficult to maintain it and it was dropped from the patchset. You can still find it on tag "perf-opencsd-v4.15" but you'll have to make modifications so that it can work again.
OK, I will try to port it on v4.16.
Right now everything that was on perf-opencsd-v4.16 has been mailined or is available in coresight next [1]. Please use that so that we can help you better.
Thanks, Mathieu
[1]. https://git.linaro.org/kernel/coresight.git/?h=next-v4.19-rc1
Leo Yan (who is on this list) was working on upstreaming a better version of the script. That was put on hold while I am trying to finish the support of CPU-wide trace scenarios.
Hi Leo, regarding your script, do you have any working version? If yes, and you willing to share, I can give it a try on my machine.
Thanks, Tomasz