Unfortunately this seems to have introduced spurious failures on (at
least) qemu_x86 and qemu_xtensa.
The change limits the timeslice tolerance to +/- 1ms, which isn't
necessarily correct when the tick rate is less than 1ms (though it
will probably work on deterministic hardware as long as the system is
hitting the target at exactly the right tick), and isn't even
theoretically achievable on emulation environments where timing
granularity is limited by the host scheduling quantum.
What this needs to do is check the deadline is off by at most one
tick, and trust the platform integration to have set the tick rate
appropriately.
(I do worry that the earlier version of the test was trying to set the
limit at half the TICKLESS_IDLE_THRESHOLD, though -- that seems weird,
and hints that maybe the test is trying to do something more
elaborate?)
Fixes#17063.
This reverts commit 62c71dc4d8.
Signed-off-by: Andy Ross <andrew.j.ross@intel.com>
c0630346c8