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

[Thomas Gleixner]

On Wed, 10 Dec 2014, Santosh Shukla wrote:
> The causes I could find:
> - Clockevent device's counter overflow: When we need to program a clockevt
>   device for times larger than it can handle, we program it for max time and
>   then reprogram again on expiration. Because of hardware counter limitations we
>   have to do it this way and this isn't really a spurious interrupt as we
>   programmed it that way.
> 
> - Hardware timer firing before its expiration: Yes, its hard to digest but from
>   my tests it looks like this does happen. Will circulate another mail once I am
>   sure about it.

Nothing we can do about.
 
> - Difference between time returned by hrtimer_update_base() and clockevt
>   device's notion of time: Wanted to discuss this here..

The clock event device and the clock source can run at different
frequencies. So the conversion from nsec to event ticks can cause
slight errors which are only observable when the delta gets larger.

The clock event device conversion from nsecs to timer ticks is
calculated at setup time once. It's known to be not completely
precise.

The clock source conversion which we use for reading time can be
changed by recalibration (we do that for TSC) and by NTP adjustments.

So even if we would calibrate the clock event device better, then we
still would need to take the NTP adjustments into account. And given
the zoo of timers we have, certainly not a trivial exercise.

Need to think about a bit more.

Thanks,

	tglx




--
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/