WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

[Xen-devel] system time skew measurement patch

To: "Xen-Devel (E-mail)" <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: [Xen-devel] system time skew measurement patch
From: "Dan Magenheimer" <dan.magenheimer@xxxxxxxxxx>
Date: Mon, 21 Apr 2008 15:00:00 -0600
Delivery-date: Mon, 21 Apr 2008 14:00:41 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Organization: Oracle Corporation
Reply-to: "dan.magenheimer@xxxxxxxxxx" <dan.magenheimer@xxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acij8qfr3eN+Hq6zQZSPY+jdn0NuoA==
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
<Prev in Thread] Current Thread [Next in Thread>