Reduce the Xen timecounter from 1GHz to 2^-9 GHz, thereby increasing the

timecounter period from 2^32 ns (~4.3s) to 2^41 ns (~36m39s).  Some time
sharing systems can skip clock interrupts for a few seconds when under
load (e.g., if we've recently used more than our fair share of CPU and
someone else wants a burst of CPU) and we were losing time in quanta of
2^32 ns due to timecounter wrapping.

Increasing the timecounter period up to 2^41 ns is definitely overkill,
but we still have microsecond timecounter precision, and anyone using
paravirtualized hardware when they need submicrosecond timing is crazy.

1 files changed, 3 insertions, 2 deletions

diff --git a/sys/i386/xen/clock.c b/sys/i386/xen/clock.c
index 5efd66d..03f2517 100644
--- a/sys/i386/xen/clock.c
+++ b/sys/i386/xen/clock.c
@@ -523,7 +523,8 @@ startrtclock()
 	set_cyc2ns_scale(cpu_khz/1000);
 	tsc_freq = cpu_khz * 1000;
 
-        timer_freq = xen_timecounter.tc_frequency = 1000000000LL;
+        timer_freq = 1000000000LL;
+	xen_timecounter.tc_frequency = timer_freq >> 9;
         tc_init(&xen_timecounter);
 
 	rdtscll(alarm);
@@ -830,7 +831,7 @@ xen_get_timecount(struct timecounter *tc)
 	
         clk = shadow->system_timestamp + get_nsec_offset(shadow);
 
-	return (uint32_t)(clk);
+	return (uint32_t)(clk >> 9);
 
 }