mirror of
https://mirrors.bfsu.edu.cn/git/linux.git
synced 2024-11-16 08:44:21 +08:00
151c8e499f
Using msleep() is problematic because it's compared against
ratelimiter.c's ktime_get_coarse_boottime_ns(), which means on systems
with slow jiffies (such as UML's forced HZ=100), the result is
inaccurate. So switch to using schedule_hrtimeout().
However, hrtimer gives us access only to the traditional posix timers,
and none of the _COARSE variants. So now, rather than being too
imprecise like jiffies, it's too precise.
One solution would be to give it a large "range" value, but this will
still fire early on a loaded system. A better solution is to align the
timeout to the actual coarse timer, and then round up to the nearest
tick, plus change.
So add the timeout to the current coarse time, and then
schedule_hrtimer() until the absolute computed time.
This should hopefully reduce flakes in CI as well. Note that we keep the
retry loop in case the entire function is running behind, because the
test could still be scheduled out, by either the kernel or by the
hypervisor's kernel, in which case restarting the test and hoping to not
be scheduled out still helps.
Fixes:
|
||
---|---|---|
.. | ||
alarmtimer.c | ||
clockevents.c | ||
clocksource-wdtest.c | ||
clocksource.c | ||
hrtimer.c | ||
itimer.c | ||
jiffies.c | ||
Kconfig | ||
Makefile | ||
namespace.c | ||
ntp_internal.h | ||
ntp.c | ||
posix-clock.c | ||
posix-cpu-timers.c | ||
posix-stubs.c | ||
posix-timers.c | ||
posix-timers.h | ||
sched_clock.c | ||
test_udelay.c | ||
tick-broadcast-hrtimer.c | ||
tick-broadcast.c | ||
tick-common.c | ||
tick-internal.h | ||
tick-legacy.c | ||
tick-oneshot.c | ||
tick-sched.c | ||
tick-sched.h | ||
time_test.c | ||
time.c | ||
timeconst.bc | ||
timeconv.c | ||
timecounter.c | ||
timekeeping_debug.c | ||
timekeeping_internal.h | ||
timekeeping.c | ||
timekeeping.h | ||
timer_list.c | ||
timer.c | ||
vsyscall.c |