[Xen-devel] system time skew measurement patch

["Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>]

The patch below printk's useful interprocessor system time skew
information.  Patch is relative to xen-unstable.  Printk is
rate-limited to output only when O(max skew) grows.  Max skew
is measured across all cores/processors... ideally eventually it
should be measured for each processor and exported via "xm info"
so groups of sync'ed processors can be properly identified.

Even on my Core 2 Duo E6850 @ 3.00 GHz (1 socket), I am seeing
skew on the order of 6000 cycles (2 usec).  I'm not clear on
whether this is due to the calibration algorithm or the
hardware.

It would be nice if this patch could be put in xen-unstable so
that we can collect measurements for many systems... it
probably could/should be removed for released bits.  (Is
there a #define that is turned off for released bits?)

Dan

diff -Naur xen.hg/xen/arch/x86/time.c patch.hg/xen/arch/x86/time.c
--- xen.hg/xen/arch/x86/time.c  2008-04-21 14:25:31.000000000 -0600
+++ patch.hg/xen/arch/x86/time.c        2008-04-21 14:26:12.000000000 -0600
@@ -841,6 +841,33 @@
     curr_master_stime = read_platform_stime();
     local_irq_enable();

+    if ( smp_processor_id() )
+    {
+        static u64 max_stime_skew = 1;
+        static unsigned int log_max_stime_skew = 1, tmplog;
+        static int first_calib = 1;
+        s64 cur_skew = curr_master_stime - curr_local_stime;
+
+        if ( first_calib )  /* no printk for first calibration */
+        {
+            first_calib = 0;
+            cur_skew = max_stime_skew;
+        }
+        if ( cur_skew < 0 )
+            cur_skew = -cur_skew;
+        if ( cur_skew > max_stime_skew )
+        {
+            max_stime_skew = cur_skew;
+            tmplog = fls(cur_skew);
+            if ( tmplog > log_max_stime_skew )
+            {
+                log_max_stime_skew = tmplog;
+                printk("proc%d: stime skew=%"PRIu64" cycles\n",
+                        smp_processor_id(), cur_skew);
+            }
+        }
+    }
+
 #if 0
     printk("PRE%d: tsc=%"PRIu64" stime=%"PRIu64" master=%"PRIu64"\n",
            smp_processor_id(), prev_tsc, prev_local_stime, prev_master_stime);


===================================
If Xen could save time in a bottle / then clocks wouldn't virtually skew /
It would save every tick / for VMs that aren't quick /
and Xen then would send them anew
(with apologies to the late great Jim Croce)

Attachment: skewcheck.patch
Description: Binary data

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel