On 30 June 2014 16:28, Preeti U Murthy preeti@linux.vnet.ibm.com wrote:
I am sceptical about what this patch does when expires is not equal to KTIME_MAX. This, being the primary timer handler function in the nohz low resolution mode, it should skip programming *only* when the tick is stopped, indicating that the cpu was in idle (which this patch takes
or in full dynticks mode..
care of) and there were no pending timers queued between the time this cpu went idle and now. If there is a pending timer, it should program the clock device even if the tick was stopped.
No, we don't need tick just for running timers. We might want to go in full dynticks mode here (not infinitely though), and if the timer is required only after say 100 ticks, we will program clkevt device for this late.
Actually frederic suggested to do something similar in High resolution mode as well, so that we can avoid double set-event for clockevent device. As we will surely get to tick_nohz_stop_sched_tick() as well..
I realise that in the irq_exit path, the periodic tick is re-started if there are pending timers, but is it right to rely on the irq exit path
Sure. I don't think we restart periodic tick unless its required. We might be reprogramming clkevt device to fire after some ticks-interval though.
for this? What if the code in the irq_exit path optimizes some parts and removes restart of periodic ticks? In which case this code will break.
It can't.
We already depend *heavily* on tick_nohz_irq_exit() for both idle and full dyntick modes. And this is considered the right place to check if ticks are required or not.
My point is the timer handler function should be self sufficient as much as possible in taking care of programming the clock device.
We probably can't handle everything from tick/timer routines. For example, suppose after tick-interrupt some task is started on the isolated/idle CPU. And by that time tick routines are already called.
And probably so its handled late in irq_exit()..
Correct me if I am wrong but I don't think any other timer handler function relies on the irq_exit path to reprogram the clock device.
I am not sure if I understood what you are pointing at completely.
There are only two timer-handler routines available, leaving periodic ones: - Lowres - The one I updated. - Highres - We already cancel hrtimer when not required.
So, yes we are depending on irq_exit() badly :)
Let me know if I am wrong somewhere :)