All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
To: yosi yarchi <yosi.yarchi@gmail.com>
Cc: linux-rt-users@vger.kernel.org
Subject: Re: high latency introduced by hrtimer_interrupt
Date: Wed, 25 May 2022 13:50:36 +0200	[thread overview]
Message-ID: <Yo4YDC1G5Ax/M4Wg@linutronix.de> (raw)
In-Reply-To: <70b2548e-4f45-cb4f-d893-0a4d59ee4faf@gmail.com>

On 2022-05-12 08:13:58 [+0300], yosi yarchi wrote:
> hi
Hi,

> I'm using linux-rt, 5.4.41, at91 sam9x35 (single core).
> 
> AFAIK, the hrtimer_interrupt must run at HW context, and could not be
> threaded.
> On my system, hrtimer_interrupt processing takes ~100us in average, ~40us in
> best case and ~200us in worst case. when adding the overhead of the
> re-scheduling that follow each interrupt, we get to worst case overhead of
> ~250us for the hrtimer_interrupt.
> This worst case and the huge variance are too high for some of my threaded
> interrupts, which have to record timestamps of HW events with precision <
> 100us.
> 
> Digging in documentation and mailing lists, I didn't find any solution...
> 
> Any idea on how to overcome this problem?

So the hrtimer runs in hardirq context for the important timer like the
system tick or a wake up of RT tasks. It can run at lower priority
(threaded) if it is a timer for non-RT tasks. Nevertheless even the
"threaded" hrtimer needs a wake up from the hard irq context. 
You could enable additional events to figure out what exactly is the
hrtimer doing (processing a specific callback, waking a task, …).

Either there is a timer doing something nasty, leading to these long
runs of the callback _or_ your CPU is simply slow and this is the best
you can get.

> With best regards
> Yosi Yarchi

Sebastian

  reply	other threads:[~2022-05-25 11:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-12  5:13 high latency introduced by hrtimer_interrupt yosi yarchi
2022-05-25 11:50 ` Sebastian Andrzej Siewior [this message]
  -- strict thread matches above, loose matches on Subject: below --
2021-06-29  4:54 Questions related to nano_sleep()/hrtimer manty kuma
2021-07-08 13:29 ` Thomas Gleixner
2022-05-12  3:39   ` high latency introduced by hrtimer_interrupt yosi yarchi

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=Yo4YDC1G5Ax/M4Wg@linutronix.de \
    --to=bigeasy@linutronix.de \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=yosi.yarchi@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.