RE: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes

["Tian, Kevin" <kevin.tian@xxxxxxxxx>]

>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
>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

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 
necessary.

Thanks
Kevin

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel