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: "Keir Fraser" <Keir.Fraser@xxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
Subject: RE: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes
From: "Tian, Kevin" <kevin.tian@xxxxxxxxx>
Date: Sat, 1 Sep 2007 22:18:31 +0800
Delivery-date: Sat, 01 Sep 2007 07:19:03 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <C2FF31EA.D26D%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: <D470B4E54465E3469E2ABBC5AFAC390F013B21B8@xxxxxxxxxxxxxxxxxxxxxxxxxxxx> <C2FF31EA.D26D%Keir.Fraser@xxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acfqh8RwaTy8r4iaT0y7Njlwu+54dgAROIeQAAbzeNkAABsToAABWQIjAB9V6qAAErBLqwAKHGtwAAEaJJoAEo/UwAAWs08+AATSlUAAAaaT2AAAE0xA
Thread-topic: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes
>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
>Sent: 2007年9月1日 22:13
>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
>> 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
>daemon could re-evaluate the ACPI objects every 5-10s for example,
>would have negligible cost. I reckon such a simple scheme would would
>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
>some ACPI event info would need to be propagated for it to see the
>C-state info.
> -- Keir

Yes, ACPI defines standard method _CST to export C-state information 
and a notification to that object is forced (as part of ACPI event like a 
GPE) at some hardware status change. Then OSPM can re-evaluate
_CST. Such event should be rare, and thus a periodical poll is not 


Xen-devel mailing list