Re: [Query] Spurious interrupts from clockevent device on X86 Ivybridge

[Viresh Kumar]

On 10 December 2014 at 18:03, Preeti U Murthy <preeti@xxxxxxxxxxxxxxxxxx> 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/