aboutsummaryrefslogtreecommitdiffstats
path: root/include/linux
diff options
context:
space:
mode:
authorjohn stultz <johnstul@us.ibm.com>2009-10-02 19:17:53 -0400
committerIngo Molnar <mingo@elte.hu>2009-10-05 07:51:48 -0400
commita092ff0f90cae22b2ac8028ecd2c6f6c1a9e4601 (patch)
tree79ec451d0bcdf6c08e0bc210b4beed694fbbf4a9 /include/linux
parent8a0382f6fceaf0c6479e582e1054f36333ea3d24 (diff)
time: Implement logarithmic time accumulation
Accumulating one tick at a time works well unless we're using NOHZ. Then it can be an issue, since we may have to run through the loop a few thousand times, which can increase timer interrupt caused latency. The current solution was to accumulate in half-second intervals with NOHZ. This kept the number of loops down, however it did slightly change how we make NTP adjustments. While not an issue with NTPd users, as NTPd makes adjustments over a longer period of time, other adjtimex() users have noticed the half-second granularity with which we can apply frequency changes to the clock. For instance, if a application tries to apply a 100ppm frequency correction for 20ms to correct a 2us offset, with NOHZ they either get no correction, or a 50us correction. Now, there will always be some granularity error for applying frequency corrections. However with users sensitive to this error have seen a 50-500x increase with NOHZ compared to running without NOHZ. So I figured I'd try another approach then just simply increasing the interval. My approach is to consume the time interval logarithmically. This reduces the number of times through the loop needed keeping latency down, while still preserving the original granularity error for adjtimex() changes. Further, this change allows us to remove the xtime_cache code (patch to follow), as xtime is always within one tick of the current time, instead of the half-second updates it saw before. An earlier version of this patch has been shipping to x86 users in the RedHat MRG releases for awhile without issue, but I've reworked this version to be even more careful about avoiding possible overflows if the shift value gets too large. Signed-off-by: John Stultz <johnstul@us.ibm.com> Acked-by: Thomas Gleixner <tglx@linutronix.de> Reviewed-by: John Kacur <jkacur@redhat.com> Cc: Clark Williams <williams@redhat.com> Cc: Martin Schwidefsky <schwidefsky@de.ibm.com> Cc: Andrew Morton <akpm@linux-foundation.org> LKML-Reference: <1254525473.7741.88.camel@localhost.localdomain> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'include/linux')
-rw-r--r--include/linux/timex.h4
1 files changed, 0 insertions, 4 deletions
diff --git a/include/linux/timex.h b/include/linux/timex.h
index e6967d10d9e5..0c0ef7d4db7c 100644
--- a/include/linux/timex.h
+++ b/include/linux/timex.h
@@ -261,11 +261,7 @@ static inline int ntp_synced(void)
261 261
262#define NTP_SCALE_SHIFT 32 262#define NTP_SCALE_SHIFT 32
263 263
264#ifdef CONFIG_NO_HZ
265#define NTP_INTERVAL_FREQ (2)
266#else
267#define NTP_INTERVAL_FREQ (HZ) 264#define NTP_INTERVAL_FREQ (HZ)
268#endif
269#define NTP_INTERVAL_LENGTH (NSEC_PER_SEC/NTP_INTERVAL_FREQ) 265#define NTP_INTERVAL_LENGTH (NSEC_PER_SEC/NTP_INTERVAL_FREQ)
270 266
271/* Returns how long ticks are at present, in ns / 2^NTP_SCALE_SHIFT. */ 267/* Returns how long ticks are at present, in ns / 2^NTP_SCALE_SHIFT. */