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] 1/2: cpufreq/PowerNow! in Xen: Time and platform

To: "Tian, Kevin" <kevin.tian@xxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes
From: Keir Fraser <Keir.Fraser@xxxxxxxxxxxx>
Date: Sat, 01 Sep 2007 15:12:42 +0100
Delivery-date: Sat, 01 Sep 2007 07:08:52 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <D470B4E54465E3469E2ABBC5AFAC390F013B21B8@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
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>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acfqh8RwaTy8r4iaT0y7Njlwu+54dgAROIeQAAbzeNkAABsToAABWQIjAB9V6qAAErBLqwAKHGtwAAEaJJoAEo/UwAAWs08+AATSlUAAAaaT2A==
Thread-topic: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes
User-agent: Microsoft-Entourage/
On 1/9/07 14:31, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:

> Yes, this is even true on native. SCI happens on one CPU with another
> CPU is decided to enter some unavailable C-state at the point. I guess
> hardware should tolerate such invalid request like taking it as a no-op
> or choosing a closest one. Software can anyway issue an invalid request
> to break report from hardware...

If this is the case, that nothing entirely terrible happens when you try to
enter an invalid C state, then it might not be critical to rely on ACPI's
event-reporting mechanisms to collect new C-state information. A dom0 user
daemon could re-evaluate the ACPI objects every 5-10s for example, which
would have negligible cost. I reckon such a simple scheme would would work
well, unless updated objects can be supplied as part of the ACPI event
mechanism, and you have to find and evaluate those? In that case I suppose
some ACPI event info would need to be propagated for it to see the modified
C-state info.

 -- Keir

Xen-devel mailing list