What version of linux should I expect to contain a version of perf that knows about libopencsd?
Debian is currently at 4.15.11. Is that new enough? It contains a tools/perf/arch/arm/util/cs-etm.c and tools/include/linux/coresight-pmu.h
but if I build perf (with make VF=1 -C tools/perf ) then Auto-detecting system features: does not mention libopencsd.
but then make it doesn't try on x86?
some clue about whether to expect this to work with 4.15.11, or if I need a newer mainline, or if that is not sufficient, and I still need the perf-opencsd-master mentioned in the HOWTO would be useful. Or perhaps https://github.com/Linaro/perf-opencsd is the place to go?
Also how does the enabling machinery work?
I can't enable this in debian until a) its in the debian mainline kernel packages and b) libopencsd is uploaded, but I can mess with it locally and get bugs filed to make it work in due course.
Wookey
On Thu, 5 Apr 2018 04:48:26 +0100 Wookey wookey@wookware.org wrote:
What version of linux should I expect to contain a version of perf that knows about libopencsd?
It looks like commit aa6292f4845e7 "perf tools: Integrating the CoreSight decoding library" went into 4.16, judging by git tag --contains output.
Debian is currently at 4.15.11. Is that new enough? It contains a tools/perf/arch/arm/util/cs-etm.c and tools/include/linux/coresight-pmu.h
but if I build perf (with make VF=1 -C tools/perf ) then Auto-detecting system features: does not mention libopencsd.
but then make it doesn't try on x86?
s/make/maybe/? No, it should. Perf is designed such that perf *record* code that gets built is platform-specific, i.e., if the target is x86, include the code to record from Intel PMUs such as BTS and PT (Processor Trace, their Coresight equivalent).
However, perf *report* code (i.e., including any arch-specific decoder libraries), gets built on all arches. So whilst we can decode Arm SPE, Coresight on x86, the x86 guys can also decode a perf.data file with intel-pt (processor-trace) on an Arm based machine.
Anyway, to answer your question, you'd need a 4.16 based kernel tree to get the perf that does things libopencsd.
some clue about whether to expect this to work with 4.15.11, or if I need a newer mainline, or if that is not sufficient, and I still need the perf-opencsd-master mentioned in the HOWTO would be useful. Or perhaps https://github.com/Linaro/perf-opencsd is the place to go?
Also how does the enabling machinery work?
IIRC the github/Linaro trees were updated, but they're not on my radar. Upstream Documentation/trace/coresight.txt doesn't specify how to explicitly enable. Perhaps this is a catch-22 situation?
In any case, 4.15 is too old.
I can't enable this in debian until a) its in the debian mainline kernel packages and b) libopencsd is uploaded, but I can mess with it locally and get bugs filed to make it work in due course.
OK, yes, Coresight decoding went in v4.16.
BTW, is this debian decoder library package going to be available for both x86 and Arm debians? I'd like to be able to do both perf record and report on the Arm target, if at all possible.
Kim
On 5 April 2018 at 10:21, Kim Phillips kim.phillips@arm.com wrote:
On Thu, 5 Apr 2018 04:48:26 +0100 Wookey wookey@wookware.org wrote:
What version of linux should I expect to contain a version of perf that knows about libopencsd?
It looks like commit aa6292f4845e7 "perf tools: Integrating the CoreSight decoding library" went into 4.16, judging by git tag --contains output.
Debian is currently at 4.15.11. Is that new enough? It contains a tools/perf/arch/arm/util/cs-etm.c and tools/include/linux/coresight-pmu.h
but if I build perf (with make VF=1 -C tools/perf ) then Auto-detecting system features: does not mention libopencsd.
but then make it doesn't try on x86?
s/make/maybe/? No, it should. Perf is designed such that perf *record* code that gets built is platform-specific, i.e., if the target is x86, include the code to record from Intel PMUs such as BTS and PT (Processor Trace, their Coresight equivalent).
However, perf *report* code (i.e., including any arch-specific decoder libraries), gets built on all arches. So whilst we can decode Arm SPE, Coresight on x86, the x86 guys can also decode a perf.data file with intel-pt (processor-trace) on an Arm based machine.
Anyway, to answer your question, you'd need a 4.16 based kernel tree to get the perf that does things libopencsd.
some clue about whether to expect this to work with 4.15.11, or if I need a newer mainline, or if that is not sufficient, and I still need the perf-opencsd-master mentioned in the HOWTO would be useful. Or perhaps https://github.com/Linaro/perf-opencsd is the place to go?
Also how does the enabling machinery work?
You definitely need a 4.16 mainline kernel - prior to that there was no support for CS trace decoding. With a 4.16 kernel simply install the libopencsd package and recompile the perf tools with option VF=1. I have tested this on my side yesterday and things should just work. Let me know if it is not the case.
As for "Documentation/trace/coresight.txt", 4.16 is a little weird as the Perf tools maintainer unexpectedly picked up patches that were destined for my tree. To avoid a merge conflict at higher levels I held back on a documentation patch that would detail the perf integration. I will submit those in the 4.17 cycle.
IIRC the github/Linaro trees were updated, but they're not on my radar. Upstream Documentation/trace/coresight.txt doesn't specify how to explicitly enable. Perhaps this is a catch-22 situation?
In any case, 4.15 is too old.
I can't enable this in debian until a) its in the debian mainline kernel packages and b) libopencsd is uploaded, but I can mess with it locally and get bugs filed to make it work in due course.
OK, yes, Coresight decoding went in v4.16.
BTW, is this debian decoder library package going to be available for both x86 and Arm debians? I'd like to be able to do both perf record and report on the Arm target, if at all possible.
Kim _______________________________________________ CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
On 2018-04-05 11:21 -0500, Kim Phillips wrote:
On Thu, 5 Apr 2018 04:48:26 +0100 Wookey wookey@wookware.org wrote:
What version of linux should I expect to contain a version of perf that knows about libopencsd?
Anyway, to answer your question, you'd need a 4.16 based kernel tree to get the perf that does things libopencsd.
OK. cheers
BTW, is this debian decoder library package going to be available for both x86 and Arm debians? I'd like to be able to do both perf record and report on the Arm target, if at all possible.
Yes, libopencsd will be built on all debian arches so you can decode arm traces on any machine. Once I have a suitably-built perf, I'll check that this does indeed work, and then enable it in the standard linux-tools build, so that anyone using packaged perf will find it all 'just works'.
I assume that the next debian stable will have at least 4.16 so this should be straightforward. There is a 4.16~rc6 in experimental already, so I'll test with that.
Wookey
On 2018-04-05 17:51 +0100, Wookey wrote:
There is a 4.16~rc6 in experimental already, so I'll test with that.
OK. So it correctly detects the library if it's installed (and doesn't if it isn't), as advertised, so simply adding libopencsd-dev to the build-deps should be all that's needed. That's slightly involved for deboian's fancy kernel packaging, but I've done it, and will file a bug with the patch.
I'm not sure how to test the resulting perf. I guess I need to record some data on arm hardware then decode that, or maybe I can use the .bin file in snapshots - is tha tthe right format/
Wookey
On 6 April 2018 at 19:22, Wookey wookey@wookware.org wrote:
On 2018-04-05 17:51 +0100, Wookey wrote:
There is a 4.16~rc6 in experimental already, so I'll test with that.
OK. So it correctly detects the library if it's installed (and doesn't if it isn't), as advertised, so simply adding libopencsd-dev to the build-deps should be all that's needed. That's slightly involved for deboian's fancy kernel packaging, but I've done it, and will file a bug with the patch.
I'm not sure how to test the resulting perf. I guess I need to record some data on arm hardware then decode that, or maybe I can use the .bin file in snapshots - is tha tthe right format/
You could try to record data but I suppose that will be a long process if you don't have any HW readily available. I can record traces and send you a "bundle". With that and following the instruction in the HOWTO.md on github you should be able to validate the openCSD package.
Let me know how you want to proceed.
Mathieu
Wookey
Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
On 2018-04-09 08:47 -0600, Mathieu Poirier wrote:
On 6 April 2018 at 19:22, Wookey wookey@wookware.org wrote:
I'm not sure how to test the resulting perf.
I can record traces and send you a "bundle". With that and following the instruction in the HOWTO.md on github you should be able to validate the openCSD package.
OK. Thanks Mathieu. I've tested that and the debian perf build does indeed decode that correctly, (and the existing 4.16 perf barfs quickly with a complaint that it can't decode it). The new one correctly depends on libopencsd so everything will work nicely for users.
So this is now essentially done from a technical POV, with just some tidying-up to do at our leisure.
1a) wait for libopencsd to get into debian. 2a) wait for new kernel to be uploaded with new dependency enabled 3a) let those migrate to testing
At this point users (of testing) are sorted.
1b) Merge my various patches, or similar functionality 2b) Do a 0.8.2 release with those in 3b) Upload that.
There is no deadline on any of 'b', but if we do it relatively soon I'll remember what the point of the patches was. In 3 months time I'll have forgotten it all :-)
Wookey
-
Kim Phillips -
Mathieu Poirier -
Wookey