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
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
On 14 September 2015 at 09:34, Al Grant Al.Grant@arm.com wrote:
Hi,
the top options for me are:
- restrict to userspace / kernelspace / both
That is taken care of by perf using cmd line options. Tracers are started accordingly but automatically doing the configuration in the tracers can't hurt.
- 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)
Process tracing is perf's signature but we need to add address range. Can you clarify what you mean by DSO and 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
Ack.
- sync frequency (however good the default is, you might want to change it)
Interesting - I'll have to get back to you on this.
- 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 recall that options. I'll look into it.
I think timestamp and 4-byte CONTEXTIDR should be enabled always... although you could have >experts-only options to disable them.
Having contextID tracing enabled all the time won't be possible when tracing a starting application but should be configurable in other circumstances.
The simpler the better really!
I agree, it has to be simple. I'll run our options by this list once the perf guys get back to me. It's one of those things that requires thinking.
Thanks for taking the time to do this, Mathieu
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
On 14 September 2015 at 16:52, Mathieu Poirier mathieu.poirier@linaro.org wrote:
On 14 September 2015 at 09:34, Al Grant Al.Grant@arm.com wrote:
- 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)
Process tracing is perf's signature but we need to add address range. Can you clarify what you mean by DSO and ASLR?
A DSO is a Dynamic Shared Object (dynamically linked library). ASLR is Address Space Layout Randomizartion (linking things at random addresses to make exploits harder to write).
Process tracing is perf's signature but we need to add address range. Can you clarify what you mean by DSO and ASLR?
Sorry, too cryptic...
DSO = dynamic shared object = dynamically loaded library (.so)
ASLR = address space randomization
What I envisage here is you might want to trace just within a DSO (if you're working on tuning it) or exclude a DSO (if it's contributing too much noise) and that would involve setting up an address filter... and if you do that, it ought to work with address space randomization.
If perf doesn't already do that for PT, don't worry about it (you'd have to hook into DSO loads somehow and I don't know if perf can do that) - I'd expect it to be an asked-for feature at some point though. Andi Kleen's presentation on PT mentions filtering by address ranges, do you know if they're exposing that in the user perf tool and if so how (symbols? modules?)
Al
- 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
Ack.
- sync frequency (however good the default is, you might want to
change it)
Interesting - I'll have to get back to you on this.
- 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 recall that options. I'll look into it.
I think timestamp and 4-byte CONTEXTIDR should be enabled always...
although you could have >experts-only options to disable them.
Having contextID tracing enabled all the time won't be possible when tracing a starting application but should be configurable in other circumstances.
The simpler the better really!
I agree, it has to be simple. I'll run our options by this list once the perf guys get back to me. It's one of those things that requires thinking.
Thanks for taking the time to do this, Mathieu
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
-- 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
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
-
Al Grant -
Mark Brown -
Mathieu Poirier -
Mike Leach