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/
Home Products Support Community News


Re: [Xen-devel] Xen cpufreq support status: how to notify hypervisor of

To: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Subject: Re: [Xen-devel] Xen cpufreq support status: how to notify hypervisor of frequency change?
From: "Matt T. Yourst" <yourst@xxxxxxxxxx>
Date: Thu, 13 Apr 2006 14:28:40 -0400
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Thu, 13 Apr 2006 14:23:51 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <1783ab10b2d5742f7362d5196ec8c1d6@xxxxxxxxxxxx>
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>
References: <200604081829.00179.yourst@xxxxxxxxxx> <200604122231.17561.yourst@xxxxxxxxxx> <1783ab10b2d5742f7362d5196ec8c1d6@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: KMail/1.8
On Thursday 13 April 2006 06:44 am, you wrote:
> Ah yes, looking closer at your code I think you are doing the right
> thing and the local_time_calibration() call should be removed.

OK, so do you think my patch (minus local_time_calibration()) would have a 
chance of getting merged? I can add basic support for non-AMD MSRs if you 
want, but can someone else with a machine actually using the speedstep and/or 
centrino cpufreq drivers will need to test it.

> Any idea if fiddling with CPU frequency affects the local APIC bus
> frequency? I would guess probably not...

I think it's just the core frequency - everything else is on separate PLLs, at 
least on K8 chips. Maybe Intel is different.

It will be interesting doing this on dual core, since I've had problems with 
cpufreq on a dual-core Athlon 64 X2 box. Each core can technically be 
adjusted independently, but the userspace cpufreq programs (cpufreqd, 
powersaved, etc) apparently do not correctly measure the system load, i.e. 
50% total CPU load runs both cores at half their maximum frequency, while 
ideally it should run one at full speed while leaving the other core idle.

This may be a problem with the load measurement algorithm rather than a kernel 
issue - as long as the MSRs are written correctly, Xen will follow along with 
whatever the dom0 kernel decides to do.

> Do you really mean the problem continues for a few *minutes* before
> 'fixing itself'?

That's correct - it can sometimes be minutes before the keyboard returns to 
normal. The frequency shift causes this, but I don't understand why it 
affects only the keyboard, only in X, and why it goes back to normal. Maybe 
there is something in the X server that instantaneously reads a bogus time 
just at the frequency transition point, and locks on to that erroneously slow 
timer until the same corner case occurs a second time? I have no idea.

If someone else could reproduce this with the patch, it might help solve it. 
It's extremely rare, so it might be difficult to reproduce.

- Matt

 Matt T. Yourst               yourst@xxxxxxxxxxxxxxxxx
 Binghamton University, Department of Computer Science

Xen-devel mailing list