On 12/10/2014 06:22 PM, Viresh Kumar wrote:
On 10 December 2014 at 18:03, Preeti U Murthy preeti@linux.vnet.ibm.com wrote:
Right. We get an interrupt when nobody had asked for it to be delivered or had asked for it to be delivered and later canceled the request. It is most often in the latter situation, that there can be race conditions. If these race conditions are not taken care of, they can result in spurious interrupts.
But the delta time will be very small then, right ?
I was talking of the case where we get an interrupt from the clockevent device but dont find the hrtimer to service and not really of an anomaly in timekeeping. For instance one of the issues that we had seen earlier wherein we cancel the tick-sched-timer before going tickless, but since we had programmed the clock event device to fire, we get a spurious interrupt.
Since the difference is 1us and not a noticeably high value, it is most probably because during hrtimer handling, we traverse all queued timers and call their handlers, till we find timers whose expiry is in the future. I would not be surprised if we overshoot the expiry of the timers at the end of the list by a microsecond by the time we call their handlers.
Looks like you misunderstood what he wrote. He isn't saying that we serviced the timers/hrtimers sometime after we should have.
What he is saying is: we got the clockevent device's interrupt at the time we requested but hrtimer_update_base() returned a time lesser than what it *should* have. And that results in a spurious interrupt.. We enqueue again for 1 us and service the timer then.
Oh ok I see. I understand this better now after reading Thomas's explanation.
Regards Preeti U Murthy