6 Apr
2021
6 Apr
'21
3:24 a.m.
On 2021/3/31 0:51, zied guermazi wrote:
Hi As far as I remember data is retrieved from the sink and put into the perf aux buffer at thread removal from the scheduler. And data can be lost here if the time slice of the scheduler is too big compared to the size of the sink. A second reason for the data loss is the size of the aux buffer, and this can be configured when mmaping the aux buffer. Kind Regards Zied Guermazi
Hi Zied,
Thanks for your reply. I've tried perf record -m, and it really help.
Qi
Gesendet von Yahoo Mail auf Android https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature
Am Di., März 30, 2021 at 6:26 PM schrieb Al Grant <Al.Grant@arm.com>: > On 30/03/2021 09:18, liuqi (BA) wrote: > > Hi Mathieu & Suzuki, > > > > Here is a question about the amount of data traced by ETM device. > > > > In high-CPU-utilization scene, volume of ETM trace data may be very > > large, but limited buffer in sink device which is used to store trace > > data can not hold all of these data. It seems that data loss in sink > > device is inevitable. > > > So how could we ensure the data we are interested in isn't lost, or > > > what > > we can do to reduce this kind of data loss? > > It depends on what configuration you have. On legacy coresight sinks (read > TMC-ETR), without an overflow interrupt we can't do much, except for > increasing the buffer size allocated for the trace collection. > For perf you could use, > > perf record -m ,<memory-for-AUX-buf> -e ... > > Also, it is not clear what "data is of interest". There is strobbing support for ETM > from Mike, which is under review. You may use it to avoid the continuous > collection of trace and use a periodic collection and thus avoiding the overflows. > Again, that may not guarantee you have the data of interest captured. You could also look at address filters, there are two kinds: An address range filter will capture trace within a given range, i.e. only code between the lower and higher address will be traced. A start/stop filter will start or stop the trace when an address is reached - for example you could stop the trace when you hit a kernel error handler. More details here: https://github.com/Linaro/OpenCSD/blob/master/HOWTO.md Al > > The solution would be to wire up the cross triggers to trigger a sink stop upon > the even of interest. This doesn't exist today. But it could be built on top of the > CTI and the complex configuration series. > > Kind regards > Suzuki > > > > > Any response will be highly appreciated. > > > > Thanks, > > Qi > > > > _______________________________________________ > CoreSight mailing list > CoreSight@lists.linaro.org <mailto:CoreSight@lists.linaro.org> > https://lists.linaro.org/mailman/listinfo/coresight _______________________________________________ CoreSight mailing list CoreSight@lists.linaro.org <mailto:CoreSight@lists.linaro.org> https://lists.linaro.org/mailman/listinfo/coresight