public inbox for linux-trace-users@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniel Bristot de Oliveira <bristot@kernel.org>
To: Prasad Pandit <ppandit@redhat.com>
Cc: linux-trace-users@vger.kernel.org
Subject: Re: About rtla osnoise and timerlat usage
Date: Wed, 22 Feb 2023 15:06:29 -0300	[thread overview]
Message-ID: <38c56e37-2805-0b93-57f6-a176e4eb98f6@kernel.org> (raw)
In-Reply-To: <CAE8KmOzuCqp5w4FBVd6GjPg_znQhumcsA=PKozZbQWxXPdZYXg@mail.gmail.com>

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@kernel.org <mailto:bristot@kernel.org>> 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


  parent reply	other threads:[~2023-02-22 18:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CAE8KmOxedTiM8GJVp+-HuBW=jkuE=aSKFYrmaj8zHLmQP-1RCg@mail.gmail.com>
2023-02-22 11:59 ` About rtla osnoise and timerlat usage Daniel Bristot de Oliveira
     [not found]   ` <CAE8KmOzuCqp5w4FBVd6GjPg_znQhumcsA=PKozZbQWxXPdZYXg@mail.gmail.com>
2023-02-22 13:15     ` Daniel Bristot de Oliveira
     [not found]       ` <CAE8KmOxV8u3v4ALVvqOUO+zvnd99d6iSXw0RiSLondvdX_JJSA@mail.gmail.com>
2023-02-23 12:12         ` Prasad Pandit
2023-02-23 14:38           ` Daniel Bristot de Oliveira
2023-02-23 14:17         ` Daniel Bristot de Oliveira
2023-02-23 14:39           ` Steven Rostedt
2023-02-23 14:54             ` Daniel Bristot de Oliveira
2023-02-27  7:10               ` Prasad Pandit
2023-02-22 18:06     ` Daniel Bristot de Oliveira [this message]
2023-02-22 19:13       ` Prasad Pandit

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=38c56e37-2805-0b93-57f6-a176e4eb98f6@kernel.org \
    --to=bristot@kernel.org \
    --cc=linux-trace-users@vger.kernel.org \
    --cc=ppandit@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox