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)
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
On 21/4/08 22:00, "Dan Magenheimer" <dan.magenheimer@oracle.com> wrote:> 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.This is not unexpected. Stick a max() function at the end of get_s_time() and we''ll be fine. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
> From: Keir Fraser [mailto:keir.fraser@eu.citrix.com] > > > <dan.magenheimer@oracle.com> wrote: > > > 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. > > This is not unexpected. Stick a max() function at the end of > get_s_time() > and we''ll be fine.All that does is change the problem from a monotonicity problem to a "time appears to be frozen" problem. While I agree that 2 usec is unlikely to be noticed by *anyone*, on systems without good tsc synchronization, this could get much larger (even when it is corrected once per second). The patch isn''t intended to fix anything, it''s just to help us determine how bad the problem is. If tsc doesn''t skew across processors more than about 10 ppm in each epoch, I agree that the max function is probably good enough. Dan _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Santos, Jose Renato G
2008-Apr-22 03:15 UTC
[Xen-devel] Question about support for acpi_cpufreq module in Xen
Does Xen support changes to the processor P-state using acpi_cpufreq module? I have an Intel core2-duo machine with 2 physical CPUs (4 logical CPUs in total) and acpi_cpufreq does not seem to work properly When I run the command cpufreq-info (in dom0), I get the following:> cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006 > Report errors and bugs to linux@brodo.de, please. > analyzing CPU 0: > driver: acpi-cpufreq > CPUs which need to switch frequency at the same time: 0 > hardware limits: 2.00 GHz - 3.00 GHz > available frequency steps: 3.00 GHz, 2.00 GHz > available cpufreq governors: userspace, performance > current policy: frequency should be within 2.00 GHz and 3.00 GHz. > The governor "userspace" may decide which speed to use > within this range. > current CPU frequency is 3.00 GHz. > analyzing CPU 1: > driver: acpi-cpufreq > CPUs which need to switch frequency at the same time: 1 > hardware limits: 2.00 GHz - 3.00 GHz > available frequency steps: 3.00 GHz, 2.00 GHz > available cpufreq governors: userspace, performance > current policy: frequency should be within 2.00 GHz and 3.00 GHz. > The governor "userspace" may decide which speed to use > within this range. > current CPU frequency is 3.00 GHz. > analyzing CPU 2: > no or unknown cpufreq driver is active on this CPU > analyzing CPU 3: > no or unknown cpufreq driver is active on this CPUIt seems acpi_cpufreq is not recognizing 2 of my CPUs. I think this problem is somehow related to the fact that if two cores share the same socket they cannot be set to distinct Power states. Xen is reporting that the 4 CPUs are in 4 distinct physical CPUs (siblings=1) when each physical CPU has 2 cores, and this may be confusing acpi_cpufreq. (see the difference in /proc/cpuinfo between Xen and Linux in the attached files). Is this a well known problem? Is there any way to fix this? I thought Xen has been fixed to report the right physical CPU topology but maybe I am wrong. Any help would be greatly appreciated Thanks Renato PS - I am using xen-unstable c/s 17193:f33328217eee _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel