-----Original Message----- From: Mathieu Poirier mathieu.poirier@linaro.org Sent: 27 April 2018 20:08 To: Robert Walker Robert.Walker@arm.com Cc: Mike Leach Mike.Leach@arm.com; Al Grant Al.Grant@arm.com; Travis Walton Travis.Walton@arm.com; coresight@lists.linaro.org Subject: Re: Upstream support for ETM strobing
On 27 April 2018 at 12:24, Robert Walker Robert.Walker@arm.com wrote:
Hi,
Strobing the ETM to reduce the amount of trace data when collecting profiles for AutoFDO seems to be working and providing useful optimizations. We’re currently working with some proof of concept patches (attached for reference) that add parameters to sysfs to configure the strobe period – before running perf record, the user must write to these parameters for each ETM. This isn’t suitable for production use as it has to be done for each ETM and the values persist after the trace session. To get this into upstream, we need to have this done by the perf record tool.
I understand there is work planned to enable more complex ETM configurations (such as strobing) from perf, possibly using a file to load register values from. Is this still the case, and if so, when is it likely to
be done?
Hi Robert,
I am currently working on supporting CPU-wide trace scenarios where I can start seeing the end of the tunnel. After that my plan was to add support for ETMv3.x/PTM trace decoding followed by support for N:N source/sink topology. Part of the latter is to introduce a way to enable more complex ETM configuration using a configuration file. In fact I already stumbled on how I want to do that and have a (very) small prototype that works.
So that is what I had in mind... But it doesn't mean I can't be talked into changing my priorities. In fact I will gladly do so if we, as a group, decide it is more important to introduce support for complex configuration before ETMv3.x/PTM decoding. I personally don't have a preference, it is simply a matter of deciding what we want to do.
I have CC'ed the coresight mailing list in order to reach a broader audience. Please speak up if you really have an issue (along with the rational) with supporting ETM complex configurations before ETMv3.x/PTM decoding.
Best regards, Mathieu
Hi Mathieu,
Looking at the follow up emails, it does seem there's a bit of thought needed to get this working well. I agree it's important to get this right and we shouldn't rush in a change for one particular use case.
We would like this to be as easy to use as possible to make AutoFDO simple for most users - maybe with some kind of wrapper script that will generate the config files and do the necessary sysfs accesses to configure it. This would be similar to AutoFDO on x86 which uses a wrapper script to select the correct PMU event number for the last branch records.
Most of Arm's focus is now on Arm v8-A platforms with ETMv4 - we're not seeing much activity on Arm v7-A platforms with ETMv3 / PTM. We have partners actively interested in AutoFDO.
Regards
Rob 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.