This is a frequent topology for CoreSight - the intervening ETF smooths out incoming trace which can be quite bursty depending on the processes being run on the cores.
Some ETF/ETBs have big enough buffers that they can capture significant amounts of trace in circular-buffer mode (with readout via the RRD register). This is useful in early stages of bringup when the ETR's path to main memory via the system interconnect may not have been established, but may also be useful to capture trace without any probe-effect on the system bus.
So it would be useful if perf test could try all possibilities on the path to the ETR - i.e. if there are ETBs on the path, put those into circular buffer mode and test those too.
One system I'm using right now has one CPU with CPU->ETB->ETB->ETR. Each ETB has an 8K buffer. So in fact it is 1:1 but with three options for where trace can be captured.
Off-list we have been discussing generic ways to specify the sink in which trace is collected, e.g. by a standard way of enumerating the possible sinks as seen from a CPU.
For example we could number the sinks seen by each CPU according to a walk of its outgoing trace path, with ETB numbered before ETR if they occur at the same level (or the other way round if you prefer).
This would cope with multiple topologies, in a generic way. It's quite similar to the way caches are represented in sysfs. If you want to test all possibilities you simply iterate through the sinks until perf tells you there are no more. For physically partitioned trace fabrics (including multi-socket) this is much simpler than specifying trace sinks individually, since an individual sink is only valid for a subset of cores.
We do predict that future topologies will move towards a 1:1 relationship between ETM and ETR - with no STF between.
Meanwhile we need to support current silicon.
Al
Another thing I noted that on several platforms (Juno, Hikey/Hikey960, DB410c), all of them only has single one ETR component, so means this testing is valid on these platforms. But ETF usage is quite diverse on different platforms, e.g. as a special case, on Juno board, one ETF even cannot create any trace path [1] so it will always fail if we use perf with it.
That's interesting. What is the purpose of such ETF? LINKSINK mode only?
This ETF is ETF1 on Juno.
On Juno, ETF0 collects data from the cores, and ETF1 attaches to the STM, SCP and system profiler. While these devices can generate trace, they are not part of the application processor trace path so are not directly controlled by perf Thus trace from the Cortex processors will never have a path that passes through ETF1. The output from ETF0 and ETF1 both funnel into the system ETR.
Regards
Mike
Thanks, Wojciech
- Is there any sink naming convention? AFAIR sysfs file names
depend on what's in DTS. I can imagine a situation where I have two ETRs with nodes names etr1@88f00f00, etr2@88f00f80 - the script will not discover them. I took a brief look at the bindings document and I don't
see any obvious remarks on how should we name DTS nodes.
Good point. I will change the code as below:
arm_cs_etr_test() {
for i in /sys/bus/coresight/devices/*.etr; do
for i in /sys/bus/coresight/devices/*.etr*; doJust want to remind (but maybe this is off topic), ePAPR [2] suggests to use node name as general as possible, so the ETR will use
'etr@xxxxxxxx'
as device node name in dts, and in theory we should always use the unified format for ETR node; anyway, will change the code with more flexible match.
Sorry if I confused something here, but perhaps this is the right moment to establish such convention?
Not at all. Thanks a lot for reviewing and suggestions!
Thanks, Leo Yan
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/t ree/ar ch/arm64/boot/dts/arm/juno-cs-r1r2.dtsi?h=v5.1-rc6#n26 [2] https://elinux.org/images/c/cf/Power_ePAPR_APPROVED_v1.1.pdf
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
-- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK _______________________________________________ CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
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.