If you look at the Kconfig files, you should see that selecting 
CONFIG_HIGH_RES_TIMERS selects TICK_ONESHOT, which means that instead of 
programming a regular interrupt timer tick the kernel will simply 
program the next required timer interrupt for the next timer that's 
going to expire, whenever that happens to be.

I *thought* that there was code to automatically adjust the priority of 
the hrtimer thread based on the priority of the process it was 
delivering the wakeup to, but maybe I'm mis-remembering.

Chris


On 6/28/2021 10:54 PM, manty kuma wrote:

I went through the source code for hrtimers and understood at a decent
level about how they are working. However, I have the following
questions.

- What is the clock source for HRTimers and what is the frequency of
this clock device?
- with timer subsystem CONFIG_HZ can go to a max of 1000 meaning at
the maximum only 1 ms latency can be reliably established. I
understand that hrtimers are not using CONFIG_HZ but i am just curious
as to what their clock source is and how 1 ns precision is achieved?
- I am using a RT kernel and I see that interrupt handlers are
executed as threaded-irqs. Is it possible to configure the priority of
the interrupt handler hrtimer_interrupt()? for a FF process, the
wakeup() is called from interrupt context(called by threaded irq)
which is actually having lesser priority than my higher priority
process. If possible I would like to change the priority of the
threaded_irq  process that handles timer interrupts. I believe this
way sleep() will not take longer than expected.(I am debugging issues
where even my FF process with prio 110 sometimes fails to wake up back
in time)

Thank you in advance!

Regards,
Manty