MFC 297039,297374,297398,297484:

Poll the IPI status while waiting constantly instead of delaying
5 microseconds between checks.  This avoids inserting a minimum
latency of 5 microseconds on each IPI.

297039:
Check IPI status more frequently when waiting.

An IPI cannot be sent via the local APIC if a previous IPI is still
being delivered.  Attempts to send an IPI will wait for a pending IPI
to clear.  Prior to r278325 these checks used a spin loop with a
hardcoded maximum count which broke AP startup on some systems.
However, r278325 also enforced a minimum latency of 5 microseconds if an
IPI was still pending which resulted in a measurable performance hit.
This change reduces that minimum latency to 1 microsecond.

297374:
Calibrate the frequency of the of the native_lapic_ipi_wait() loop,
and avoid a delay while waiting for IPI delivery acknowledgement in
xAPIC mode.  This makes the loop exit immediately after the delivery
bit in APIC_ICR register is set, instead of waiting for some
microseconds.

We only need to ensure that some amount of time is allowed for the
LAPIC to react to the command, and we need that the wait time is
finite and reasonable.  For that reasons, it is irrelevant if the CPU
frequency or throttling decrease the speed and make the loop,
calibrated for full CPU speed at boot time, execute somewhat slower.

297398:
Fix several bugs in r297374:
- fix UP build [1]
- do not obliterate initial reading of rdtsc by the loop counter [2]
- restore the meaning of the argument -1 to native_lapic_ipi_wait()
  as wait until LAPIC acknowledge without timeout
- correct formula for calculating loop iteration count for 1us, it was
  inverted, and ensure that even on unlikely slow CPUs at least one
  check for ack is performed.

297484:
Style(9), use tabs for the #define LOOPS line.
Print unsigned values with %u.
Make code slightly more compact by inlining loop limit.

0 files changed, 0 insertions, 0 deletions