summaryrefslogtreecommitdiffstats
path: root/kernel/hrtimer.c
diff options
context:
space:
mode:
authorjohn stultz <johnstul@us.ibm.com>2007-07-24 18:38:34 -0700
committerLinus Torvalds <torvalds@woody.linux-foundation.org>2007-07-25 10:17:44 -0700
commit17c38b7490b3f0300c7812aefdae2ddda7ab4112 (patch)
tree0f7a9ee0c691aef3497030e38c3ba8e3c13a985c /kernel/hrtimer.c
parent2c6b47de17c75d553de3e2fb426d8298d2074585 (diff)
downloadop-kernel-dev-17c38b7490b3f0300c7812aefdae2ddda7ab4112.zip
op-kernel-dev-17c38b7490b3f0300c7812aefdae2ddda7ab4112.tar.gz
Cache xtime every call to update_wall_time
This avoids xtime lag seen with dynticks, because while 'xtime' itself is still not updated often, we keep a 'xtime_cache' variable around that contains the approximate real-time that _is_ updated each time we do a 'update_wall_time()', and is thus never off by more than one tick. IOW, this restores the original semantics for 'xtime' users, as long as you use the proper abstraction functions (ie 'current_kernel_time()' or 'get_seconds()' depending on whether you want a timespec or just the seconds field). [ Updated Patch. As penance for my sins I've also yanked another #ifdef that was added to avoid the xtime lag w/ hrtimers. ] Signed-off-by: John Stultz <johnstul@us.ibm.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'kernel/hrtimer.c')
-rw-r--r--kernel/hrtimer.c4
1 files changed, 0 insertions, 4 deletions
diff --git a/kernel/hrtimer.c b/kernel/hrtimer.c
index a7bb05e..c21ca6b 100644
--- a/kernel/hrtimer.c
+++ b/kernel/hrtimer.c
@@ -141,11 +141,7 @@ static void hrtimer_get_softirq_time(struct hrtimer_cpu_base *base)
do {
seq = read_seqbegin(&xtime_lock);
-#ifdef CONFIG_NO_HZ
- getnstimeofday(&xts);
-#else
xts = current_kernel_time();
-#endif
tom = wall_to_monotonic;
} while (read_seqretry(&xtime_lock, seq));
OpenPOWER on IntegriCloud