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] [PATCH] Disable Xen PowerNow! support on Opteron 2nd gen

To: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] Disable Xen PowerNow! support on Opteron 2nd gen and earlier processors
From: "Langsdorf, Mark" <mark.langsdorf@xxxxxxx>
Date: Mon, 4 Feb 2008 15:52:22 -0600
Cc: Ian Pratt <Ian.Pratt@xxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 04 Feb 2008 13:53:17 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C3C9F79E.13315%Keir.Fraser@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: <1449F58C868D8D4E9C72945771150BDF020772A4@xxxxxxxxxxxxxxxxx> <C3C9F79E.13315%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: AchfqSS0Yzu1EMucEdyNUQAWy6hiGQAC1IswAA/P2j0ABsqr4AB6NDvwABlGPxsAAWGaZgABpF1vAKGkcSAAJeuYcAB7ldPA
Thread-topic: [Xen-devel] [PATCH] Disable Xen PowerNow! support on Opteron 2nd gen and earlier processors
> What are the deltas when time goes backwards? Bear in mind we already
> default to being silent for backwards deltas up to 10ms. 

Largest observed delta was 36 ms; it was a bit of an outlier.
Most deltas were around 20 ms.  I totaled 45 deltas over 10 ms
in 6 days with a frequency change every 15 seconds.

I think we can do better than that.  There's lots of <1 ms
regressions happening, roughly 1 every other 4 transitions.

> The issue here could well be that if you take a timer 
> interrupt towards the
> end of a frequency change but before Xen has been told that 
> the frequency
> has changed, the time values that Xen and dom0 calculate will 
> be off by
> potentially quite a bit. It's a small window of opportunity, 
> but clearly you
> hit it a few times each day. I'm not sure how easy it is to 
> close off that
> window cleanly with the MSR twiddling being controlled from dom0...

Would turning off interrupts solve it?  It might be a bit brute
force, but there's certainly a prechange notifier event and a 
postchange notifier event to use to turn them on and off.

Alternately, the prechange event could sleep until woken by
the timer interrupt, which would increase the chance that all 
frequency changes take place at the start of an interrupt.

-Mark Langsdorf
Operating System Research Center

Xen-devel mailing list