summaryrefslogtreecommitdiffstats
path: root/kernel/time
diff options
context:
space:
mode:
authorjohn stultz <johnstul@us.ibm.com>2009-02-18 16:02:22 -0800
committerIngo Molnar <mingo@elte.hu>2009-02-19 10:10:08 +0100
commitfdcedf7b75808dd72c3cc0b931be11b04d75c60a (patch)
treec64743890ffa9722f8705ce0c214f0f08ffe4d9a /kernel/time
parentba95fd47d177d46743ad94055908d22840370e06 (diff)
time: apply NTP frequency/tick changes immediately
Since the GENERIC_TIME changes landed, the adjtimex behavior changed for struct timex.tick and .freq changed. When the tick or freq value is set, we adjust the tick_length_base in ntp_update_frequency(). However, this new value doesn't get applied to tick_length until the next second (via second_overflow). This means some applications that do quick time tweaking do not see the requested change made as quickly as expected. I've run a few tests with this change, and ntpd still functions fine. Signed-off-by: John Stultz <johnstul@us.ibm.com> Signed-off-by: Ingo Molnar <mingo@elte.hu>
Diffstat (limited to 'kernel/time')
-rw-r--r--kernel/time/ntp.c7
1 files changed, 7 insertions, 0 deletions
diff --git a/kernel/time/ntp.c b/kernel/time/ntp.c
index f5f793d9241..e1fa3689a90 100644
--- a/kernel/time/ntp.c
+++ b/kernel/time/ntp.c
@@ -51,6 +51,7 @@ static long ntp_tick_adj;
static void ntp_update_frequency(void)
{
+ u64 old_tick_length_base = tick_length_base;
u64 second_length = (u64)(tick_usec * NSEC_PER_USEC * USER_HZ)
<< NTP_SCALE_SHIFT;
second_length += (s64)ntp_tick_adj << NTP_SCALE_SHIFT;
@@ -60,6 +61,12 @@ static void ntp_update_frequency(void)
tick_nsec = div_u64(second_length, HZ) >> NTP_SCALE_SHIFT;
tick_length_base = div_u64(tick_length_base, NTP_INTERVAL_FREQ);
+
+ /*
+ * Don't wait for the next second_overflow, apply
+ * the change to the tick length immediately
+ */
+ tick_length += tick_length_base - old_tick_length_base;
}
static void ntp_update_offset(long offset)