Re: Questions related to nano_sleep()/hrtimer

[Chris Friesen <chris.friesen@windriver.com>]

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
>