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
