high latency introduced by hrtimer_interrupt

high latency introduced by hrtimer_interrupt

[yosi yarchi]

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?

With best regards
Yosi Yarchi

Re: high latency introduced by hrtimer_interrupt

[Sebastian Andrzej Siewior]

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

high latency introduced by hrtimer_interrupt

[yosi yarchi]

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?


With best regards
Yosi Yarchi