Hi Srdjan,
Hello,
I have a Jetson TX2 board which has dual-core NVIDIA Denver2 + quad-core ARM Cortex-A57.
nVidia recently released a new SDK package (which they call JetPack, based on Ubuntu and 4.9 Kernel). out of the box it comes with coresight disabled, so I had to recompile the kernel in order to enable it. Coresight kind of works, I'm getting some data out of it, but I'm trying to use Perf in order to do the tracing.
The issue I'm facing is that when I execute:
perf record -e cs_etm/@8030000.etf/u --per-thread uname
it works properly, and I'm getting great reports, but if I omit the --per-thread parameter I'm getting the: failed to mmap with 12 (Cannot allocate memory)
Mainline Linux does not yet contain CPU-wide tracing. If you use mainline or older, you can trace only single-thread applications in per-thread mode. Skipping --per-thread flag is equivalent to specifying --all-cpus flag and this mode is not yet supported in mainline.
Mathieu and friends are working on CPU-wide tracing and their v2 patch set has just appeared on this list. You can try to cherry-pick their patches on your branch. Then, you will be able to use --cpu <n> and --all-cpus. I did that (with v1) and I can confirm it works well.
mmap error also happens if I want to record already running process with --pid parameter.
I tried that yesterday and it worked for me. Please mind I'm using Linux 5.1-rc1 (cloned about a week ago) with CPU-wide tracing patch set by Linaro. CoreSight development goes rapidly, so it's a good idea to keep up with this list and Linux mainline changelog, because interesting changes may appear any day.
If I specify the number of the cpu: perf record -e cs_etm/@8030000.etf/u --cpu 0 uname
then recording works but when I try to do perf report it says: 0x228 [0x40]: failed to process type: 7
What might be interesting to mention is that the processors on this system are arranged in weird combination. cpu 0,3,4,5 are ARM cores which have coresight on them, and cpu 1,2 are Denver cores without coresight. I'm suspecting that this might create some issues.
I'm not an expert, but I don't think it would matter. If Denver cores don't have CoreSight, that probably means they don't have ETMs connected, thus they will not generate any trace data. I don't know if Linux can schedule processes on them. If not, I see no harm - your program will be traced no matter what CPU kernel puts it on. If it can, the worst case would be empty trace. You can save yourself from the latter by scheduling your process with taskset to the main cores only, omitting Denvers. But again, it's just my educated guess and I'd wait for the second opinion of the wise people residing here.
Regards, Wojciech
Do you have any ideas on how to proceed to diagnose the issue?
Thank you.