On 10 December 2014 at 18:03, Preeti U Murthy <pre...@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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
