On 2/22/23 09:39, Prasad Pandit wrote: > Hello Daniel, > > Thank you so much for your reply, I appreciate it. > > On Wed, 22 Feb 2023 at 17:30, Daniel Bristot de Oliveira <bristot@xxxxxxxxxx <mailto:bristot@xxxxxxxxxx>> wrote: > > This is the timerlat's timer, so it is expected. What this trace is pointing is to > a possible exit from idle latency... so idle tune is required for this system > and *this metric*... but > > > * Idle tune? ops, I did not reply to this: idle tuning is configuring the system to avoid deep idle states. An easy way to do it is either setting idle=poll or enabling the "--dma-latency 0" in timerlat. But this is only a "problem" for timerlat/cyclictest, not for oslat/osnoise as they measure the noise as they run - so they CPU does not go idle. > > Yes, that is expected on timerlat in an isolated CPU. But not with osnoise/oslat kind of tool, > as they keep running, while timerlat/cyclictest go to sleep. > > > * I see, okay. > > Let me know how rtla osnoise results are, so I can help more. > > > * Yes, I've been running oslat(1) and rtla-osnoise(1) too. > Please see: > oslat(1) log -> https://0bin.net/paste/T0PDXHz5#AnNEzkTRxQVT1gvAqKM43jW+yhqilbNbFqHIHHpy4MY <https://0bin.net/paste/T0PDXHz5#AnNEzkTRxQVT1gvAqKM43jW+yhqilbNbFqHIHHpy4MY> > rtla-osnoise-top(1) log -> https://0bin.net/paste/8qwjebnZ#22sfTYTv68JAAMHZJhnCBTP-uvP7Mxj8ipAVbuQVsiy <https://0bin.net/paste/8qwjebnZ#22sfTYTv68JAAMHZJhnCBTP-uvP7Mxj8ipAVbuQVsiy> > > Thank you. > --- > - P J P
|