[PATCH 2/3] delay: Add explanation of udelay() inaccuracy
From: John Stultz
Date: Fri Jan 27 2017 - 20:08:07 EST
From: Russell King <rmk+kernel@xxxxxxxxxxxxxxx>
There seems to be some misunderstanding that udelay() and friends will
always guarantee the specified delay. This is a false understanding.
When udelay() is based on CPU cycles, it can return early for many
reasons which are detailed by Linus' reply to me in a thread in 2011:
However, a udelay test module was created in 2014 which allows udelay()
to only be 0.5% fast, which is outside of the CPU-cycles udelay()
results I measured back in 2011, which were deemed to be in the "we
don't care" region.
test_udelay() should be fixed to reflect the real allowable tolerance
on udelay(), rather than 0.5%.
Cc: David Riley <davidriley@xxxxxxxxxxxx>
Cc: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Cc: Richard Cochran <richardcochran@xxxxxxxxx>
Cc: Prarit Bhargava <prarit@xxxxxxxxxx>
Cc: Ingo Molnar <mingo@xxxxxxxxxx>
Signed-off-by: Russell King <rmk+kernel@xxxxxxxxxxxxxxx>
Signed-off-by: John Stultz <john.stultz@xxxxxxxxxx>
include/linux/delay.h | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/include/linux/delay.h b/include/linux/delay.h
index a6ecb34..2ecb3c4 100644
@@ -5,6 +5,17 @@
* Copyright (C) 1993 Linus Torvalds
* Delay routines, using a pre-computed "loops_per_jiffy" value.
+ * Please note that ndelay(), udelay() and mdelay() may return early for
+ * several reasons:
+ * 1. computed loops_per_jiffy too low (due to the time taken to
+ * execute the timer interrupt.)
+ * 2. cache behaviour affecting the time it takes to execute the
+ * loop function.
+ * 3. CPU clock rate changes.
+ * Please see this thread:
+ * http://lists.openwall.net/linux-kernel/2011/01/09/56