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 ?
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.
Or am I missing something ?
-- viresh