LAPIC eventtimer TSC deadline mode implementation

[kib]

Summary

Starting at least from SandyBridge, Intel provides yet another mode for the one-shot LAPIC timer interrupt, TSC deadline. The mode is very fast and easy to use, if LVT is already set up. Only a write to IA32_TSC_DEADLINE MSR is needed, which specifies TSC value. When TSC counter is incremented up to the written value, interrupt is delivered. More, the MSR write is not serializing, so all is indeed fast and easy.

More, Intel claims that the mode, besides ease of use, offer less jitter and increase precision of the interval timers, because it _can_ deliver interrupt at the precise moment. I am not sure that this is actually that good, but also I did not measured the thing yet.

[kib]

sys/x86/x86/local_apic.c

130 ↗

(On Diff #14595)

The original u_long type there is puzzling (see also a note below about uint32_t cast for one-shot mode).

789 ↗

(On Diff #14595)

Is there better way to calibrate the frequency ? Obviously the TSC deadline interrupt precision highly depends on the calibration.

825 ↗

(On Diff #14595)

I am puzzled why the cast to uint32_t was used there. Was it used to simplify the code, by allowing simpler multiplication (32x64, as opposed 64x64) ?

1177 ↗

(On Diff #14595)

This is to avoid useless LAPIC_LVT_TIMER reload if we are reset the timer before deadline. I was too chicken and did not the same optimization for oneshot mode.

[kib]

Remove unneeded mfence before write to LVT_TIMER in deadline mode.

Remove unneeded write to LVT_TIMER in deadline mode. The timer is disabled by simple zeroing of MSR TSC_DEADLINE.

[mav]

It is generally fine for me, except the comment about pointless calibration.

Does this mode actually give us some benefits? Won't extra rdtsc() affect the performance? Saving one second on boot is good, but won't it cost us instead on every call?

sys/x86/x86/local_apic.c

789 ↗

(On Diff #14595)

We already have TSC frequency for timecounter and DELAY() purposes. Why would we need to calibrate it here, especially using DELAY, which itself uses TSC? :)

825 ↗

(On Diff #14595)

Probably so. Previously frequency there by definition could never be above 32bits due to LAPIC timer calibration specifics. But with use of TSC that will no longer be true.

1177 ↗

(On Diff #14595)

OK, but does it change anything? On my profiling I've seen significant delays on register reads, but I don't remember about writes.

[kib]

sys/x86/x86/local_apic.c

789 ↗

(On Diff #14595)

Are you suggesting to do

et->et_frequency = tsc_freq;

there instead of DELAY ?

1177 ↗

(On Diff #14595)

Well, since the target moment of the interrupt is specified by the TSC value, the timer should become more precise when you compare interrupt moment and TSC value. As far as I understand, this is the main point of Intel introducing the mode.

But after the mode was introduced, Intel wants users to migrate to it, i.e. deadline is considered to be the way to go, while one-shot with the divisor is 'legacy'. I implemented it as a part of the continuous work to migrate us to use modern platform features.

If you have a tool to measure either kevent or posix timers jitter, I am very willing to apply it and see whether there are any practical changes. The mode replaces two APIC (MSR or MMIO) register writes by one MSR write. In xAPIC mode, MMIO is serializing.

[mav]

sys/x86/x86/local_apic.c

789 ↗

(On Diff #14595)

Yes. Any reason not to?

1177 ↗

(On Diff #14595)

I've sent you my timer testing tool that I used when worked on this last time.

[kib]

Use tsc_freq directly as the deadline timer frequency.

[kib]

Cosmetics. Remove unused period and intr_enable arguments from lapic_timer_{oneshot,periodic,deadline} functions. In fact, for oneshot they are used, but only once for the calibration, which is used only once, but args are passed for each case of timer re-arm. For this use, I created lapic_timer_oneshot_nointr() specific method.