On Thu, 23 Apr 2020 at 08:14, Mike Leach mike.leach@linaro.org wrote:
Hi,
On Thu, 23 Apr 2020 at 14:49, zied guermazi guermazi_zied@yahoo.com wrote:
hi Al the info you requested below is very helpful for the application that has to deal with the stream of traces. currently, the perf application is collecting the info from different sources (mostly sysfs ) and writes them in a "pseudo" perf event (AUX_INFO) in the traces recorded in a file, so that they can be processed later on. it would be very helpful if the kernel can publish such an event itself with info needed to process the traces. this event can be provided either in the data area or in the aux area. the advantage is that this can allow tracing multiple processes at the same time.
Kind Regards Zied Guermazi
On Wednesday, April 22, 2020, 06:02:45 PM GMT+2, Al Grant al.grant@arm.com wrote:
We could add the "sinkid" of the sink selected. (which we now specify for sink selection), similar to the traceid for ETMs.
I think using the sinkID is the only possible solution. Regarding implementation, the version number in the private auxtrace header has to be increased. From there and for each CPU entry, the sinkID of the sink that was selected for the session is added. That way there is no confusion as to how the system was configured.
This looks like a more serious modification than I was thinking about
- but certainly feasible
It would be useful to have generic information as well e.g.
- a flag to indicate memory (i.e. ETR) vs. ETB
- size
- a flag saying whether the buffer is in circular buffer (wrapping) mode or
is set up to trigger a trace stop before reaching its limit
- a unique index
All the above is reasonable - but what does the "unique index" represent - is that the sinkid?
The kernel has all that information, and it could help when interpreting what we're seeing in the AUX buffers (truncation flags etc.) and setting strobe parameters.
Exactly how it's arranged is a detail, e.g. could be a list of sinks followed by a list of CPUs with each CPU having a sink index... or whatever.
Currently the perf.data files are self-contained and can (mostly) be processed on a different system from the one they are generated on, as all the info is in headers, info records etc. There is a whole set of headers with details on cache / NUMA topology etc. so that consumers can interpret the data. Sink ids unique to the current system may be useful but they shouldn't be the only way of finding properties of the sinks.
Al
might work for perf, but not sysfs. I propose therefore that it is logged in the same way as the registration sign-ons for each of the components. Alternative suggestions welcome.
I think we could limit this to perf mode, as we don't know which ETMs are going to be used.
For sysfs mode, we know which ETMs are included and it should be left to the user to select the sinks and collate them as needed.
I agree.
Seems to me in general sysfs mode leaves the sink enabled. The same will be true if this is auto-selected - so finding out which sink was selected takes care of itself. I think it is important to allow this feature in sysfs - for people who are exploring systems. and it eases writing generic test scripts if trace can be obtained purely by activating an ETM.
Given that Al's related mail on this list relating to EL2 kernel trace also seems to require information on kernel option selection, the best way forward seems to be:-
- a respin of this set to use the ETR first algorithm - without the
additional information at present. One motivation for producing this set is that automatic sink selection / default operation is useful in complex config.
Yes, please proceed this way. At the very least you can move forward on complex configuration and it gives us time to assess what the next steps should be.
- An investigation is required to update the AUXTRACE headers to
allow additional information to be passed from automated driver option selection / configuration information to the user side perf code.
Regards
Mike
Suzuki
Regards
Mike
On Tue, 21 Apr 2020 at 18:40, Mathieu Poirier mathieu.poirier@linaro.org wrote:
On Tue, Apr 21, 2020 at 01:51:41PM +0100, Mike Leach wrote: > Hi Suzuki, > > On Tue, 21 Apr 2020 at 12:09, Suzuki K Poulose suzuki.poulose@arm.com
wrote:
>> >> On 04/21/2020 11:41 AM, Mike Leach wrote: >>> Hi Al, >>> >>> On Thu, 16 Apr 2020 at 22:03, Al Grant Al.Grant@arm.com wrote: >>>> >>>>> This patchset provides a proposed infrastructure to allow for >>>>> the automatic selection of a sink during CoreSight tracing operations. >>>>> >>>>> Currently starting tracing using perf requires a sink >>>>> selection on the command >>>>> line:- >>>>> >>>>> sudo ./perf record -e cs_etm/@tmc_etr0/ --per-thread uname -a >>>>> >>>>> After this set the infrastructure will be able to select a >>>>> default sink:- >>>>> >>>>> sudo ./perf record -e cs_etm// --per-thread uname -a >>>>> >>>>> This matches with the default operation provided with perf and
intelpt.
>>>>> >>>>> The CoreSight infrastructure is updated to allow the concept of a
"principal sink".
>>>>> For any given source there could be multiple possible sinks >>>>> available for selection. However, there are no good >>>>> programmatic ways to determine the optimal sink for a given >>>>> topolgy. For any given rule (e.g. first sink found, first ETR, last ETR),
there exists a possible platform / topology that will not be suitable.
>>>> >>>> While "first ETR" may not be optimal or even possible, it >>>> nearly always is both optimal and possible. So it's a good >>>> default rule and it would be useful to have a default rule. >>>> That would allow -e cs_etm// to immediately do something useful >>>> with most devices and with ACPI, in advance of an ACPI binding for the
"principal_sink" flag.
>>>> >>> >>> That's certainly feasible - and would potentially benefit any >>> system without updated bindings, not just ACPI >> >> I agree. I am leaning towards more of the automatic detection >> than the firmware specifying it. I understand that this is >> complex, given the possible configurations. >> >> May be we could limit our logic to : >> >> 1) Principal sinks are always ETR, nothing else. (We don't have >> to support legacy systems without ETR). >>
I definitely favour a kernel oriented approach to a FW specific one. I also like the idea of "ETR and nothing else". When I thought about this problem I envisioned assigning weights to each sink component. Only considering ETR is meaner but better.
> > I don't think there is too much extra effort to prioritize ETR > whenever present, but where there is no ETR, select what is available. > > >> 2) Track how many ETMs can reach an ETR and this can be a good >> indicator to select the sink automatically given a choice of >> multiple ETRs. (This involves a bit of work). i.e, choose the "available" >> ETR with lowest number of ETMs connected. >> > > I am hard pressed to figure a topology where the first ETR found > after an ETM is not also the least connected ETR. Even a 1:1 with > an additional global ETR via replicator still needs a funnel > before the global ETR, ensuring the global ETR is further away. > > Perhaps the first approach could be to implement the 1st ETR / 1st > Sink approach for principal / default sink, and revisit specific > tagging should a use case arise.
As Al pointed out we will find exotic topologies. Since all components, configurable or not, show up in the topology, a "select closest ETR" heuristic should do the trick.
> > Regards > > Mike > >> And this should solve the 1:1 configurations and per cluster ETR >> and one ETR per system. >> >> This can be a one time list, updated when there is a change in >> the system (ETR added, ETM registered). >> >> Thoughts ? >> >> Suzuki >> >>> >>> Regards >>> >>> Mike >>> >>>>> Therefore, we select the principal sink using a property in the device
tree.
>>>>> This allows the routine to select the best possible for the situation. >>>>> >>>>> The only rule for selecting such sinks, is that there should >>>>> only be one principal sink marked for any given source, across >>>>> all possible paths from that source to any sinks. (if this >>>>> rule is violated then the first found will be used) >>>>> >>>>> Therefore to select a sink, we start with the source, and walk >>>>> the child connections until a sink marked as a principal sink is found. >>>>> >>>>> Applied to Linux 5.7-rc1 (with dts updates 1,2), tested on >>>>> Juno / DB410 >>>>> >>>>> Note A: Moving forward to topologies which have groups of >>>>> sources going to dedicated sinks e.g. multisocket / >>>>> multicluster where each socket / cluster has a sink, then multiple
sinks can be marked as principal sink, one for each cluster.
>>>>> The same applies to 1:1 ETM:sink topolgy were each sink will be
marked.
>>>>> >>>>> Note B: The current set does not auto-select when using sysfs, >>>>> but I believe this could easily be added. >>>>> >>>>> [1] >>>>> https://lists.linaro.org/pipermail/coresight/2020-April/003819 >>>>> .html [2] >>>>> https://lists.linaro.org/pipermail/coresight/2020-April/003821 >>>>> .html >>>>> >>>>> Mike Leach (5): >>>>> coresight: Add principal sink handling to CoreSight base >>>>> coresight: tmc: Add principal sink attribute detection >>>>> coresight: etm: perf: Add default sink selection to etm perf >>>>> perf: cs-etm: Allow no CoreSight sink to be specified on command
line
>>>>> dt-bindings: arm: qcom: Add CoreSight principal sink >>>>> select parameters >>>>> >>>>> arch/arm64/boot/dts/arm/juno-base.dtsi | 1 + >>>>> arch/arm64/boot/dts/qcom/msm8916.dtsi | 1 + >>>>> .../hwtracing/coresight/coresight-etm-perf.c | 20 >>>>> +++++++++-- drivers/hwtracing/coresight/coresight-priv.h | 2 ++ >>>>> drivers/hwtracing/coresight/coresight-tmc.c | 9 +++++ >>>>> drivers/hwtracing/coresight/coresight.c | 34
+++++++++++++++++++
>>>>> include/linux/coresight.h | 7 ++++ >>>>> tools/perf/arch/arm/util/cs-etm.c | 6 ++-- >>>>> 8 files changed, 74 insertions(+), 6 deletions(-) >>>>> >>>>> -- >>>>> 2.17.1 >>>> >>>> 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.
>>> >>> >>> >> > > > -- > Mike Leach > Principal Engineer, ARM Ltd. > Manchester Design Centre. UK
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. _______________________________________________ CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
-- Mike Leach Principal Engineer, ARM Ltd. Manchester Design Centre. UK