Hi Mathieu,
Most of the trace configuration options relate to the amount of trace produced in a given trace run. Essentially the user has to balance the comprehensiveness of the trace against the length of trace that can be captured in the fixed buffer size (important when capturing on the target platform).
i.e. if I trace all cores in a cluster through all applications and the kernel, then trace will be comprehensive, but not much will fit into the buffer, whereas I can filter according to address and context and limit trace to application space and see more of what may be needed.
I would say there are two types of options:- a) simple on / off that affect the amount of trace generated globally (e.g. timestamps, cycle accurate trace). b) filtering options that affect where and when the trace is captured (e.g. address ranges, filter against core state - S/NS, context ID, VMID).
I would start from a clear default setup - and allow the user to add/remove features as required.
i) No initial filtering. ii) timestamps are useful if perf has built in features to correlate trace using them, but the frequency they are produced at should be handled with care to avoid having trace data with a very high percentage of timestamps. iii) I my view it would be sensible to default cycle accurate trace to off -> the user will know if they really need it, and can then switch it on if required. For investigating where a program is going wrong it is probably not needed. You get more trace that way. iv) Context ID trace is fine - assuming that context IDs are actually associated with real things in Linaro e.g. ContextID == application PID or some such.
From this base I would suggest:- 1) need to be able to set trigger points to stop trace according to an event/ address. With capture space limited this is essential to get trace at the point of interest. 2) Limit trace to selected core(s) - especially if we are tracing an application pinned to a particular core. 3) Filtering by address range and / or context ID. 4) timestamp and cycle accurate trace control.
Regards
Mike
---------------------------------------------------------------- Mike Leach +44 (0)1254 893911 (Direct) Principal Engineer +44 (0)1254 893900 (Main) Arm Blackburn Design Centre +44 (0)1254 893901 (Fax) Belthorn House Walker Rd mailto:mike.leach@arm.com Guide Blackburn BB1 2QE ----------------------------------------------------------------
-----Original Message----- From: Al Grant Sent: 14 September 2015 16:34 To: Mathieu Poirier; Mike Leach Cc: coresight@lists.linaro.org Subject: RE: Coresight configuration options
Hi,
the top options for me are:
- restrict to userspace / kernelspace / both
- restrict to one process, or an address range (whatever perf for Intel PT offers
here - if it has an option to restrict trace to a specific DSO or the main executable, that would be ideal... would be nice if it worked with ASLR)
- cycle accurate vs. non cycle accurate: I almost always use cycle-accurate but
we must give people the option to disable it in case of overflow or buffer size problems
- sync frequency (however good the default is, you might want to change it)
- branch broadcasting / disable return stack - not generally needed, but useful
when diagnosing a broken decode due to JIT etc. (default should be return stack enabled and branch broadcast disabled).
I think timestamp and 4-byte CONTEXTIDR should be enabled always... although you could have experts-only options to disable them.
The simpler the better really!
Al
-----Original Message----- From: Mathieu Poirier [mailto:mathieu.poirier@linaro.org] Sent: 14 September 2015 15:53 To: Al Grant; Mike Leach Cc: coresight@lists.linaro.org Subject: Coresight configuration options
Al and Mike,
With the work on coresight/Perf integration proceeding as planned the time
to
start looking at how configuration parameters can be conveyed to the tracers using the perf cmd tool is fast approaching, and that's where I need to pick
your
brain.
In your opinion and based on your experience with coresight, what are the 5 most wanted configuration options we need to start with?
The question could also be thought of as the 5 most common thing people configure when using coresight. Finding a way to give access to all the configuration option of a tracer via cmd line won't be easy but I believe it can be done. If we find a way to address the most commonly used options as an starting point the rest should come easily.
Please think about it and get back to me. My plan is to get the discussion
going
with the perf maintainer about the best way to proceed sometime this week
or
the next, depending on schedule.
Thanks, Mathieu
-- 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.
ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782