Avoid a race when we're setting the event timer while going idle

[jtl]

Summary

Avoid a race when we're setting the event timer while going idle by not reading the next event until we hold the lock and are ready to set the timer.

Previously, cpu_idleclock() could race with another thread trying to set an earlier event. cpu_idleclock() would read the next event time. The other thread would set an earlier event. Then, cpu_idleclock() would acquire the lock and set the event timer based on the later event it had previously read.

By acquiring the lock before reading the next event, cpu_idleclock() will get a consistent view of the next event. And, the other thread will get a consistent view of the state of the timers which are actually set.

Test Plan

I ran this against a test which measured the delay encountered by direct timeouts. With this change and D14827 and D14826, it appears that all the spurious delays have been eliminated, and the delay from the deadline averaged 2.111 microseconds with a 2.505749 standard deviation.

[kib]

What are the delays without these changes ?

[jtl]

In D14828#311827, @kib wrote:

What are the delays without these changes ?

Without this change, I saw callouts periodically have 2ms delays on an idle system. After this change (which was applied on top of the other two changes referenced in the description), the 2ms delays went away.

[• hselasky]

Make sure you also check this code with:
debug.witness.skipspin=0

In /boot/loader.conf

--HPS

[mav]

It slightly increases lock hold time, which may be a bottleneck in case of a global lock/timer, but it probably does not worth overcomplication to avoid only that.