Messages in this thread | | | Date | Wed, 10 Dec 2014 18:22:32 +0530 | Subject | Re: [Query] Spurious interrupts from clockevent device on X86 Ivybridge | From | Viresh Kumar <> |
| |
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
| |