| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
RE: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform
>From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
>Sent: 2007年9月2日 0:42
>
>On 1/9/07 16:45, "Tian, Kevin" <kevin.tian@xxxxxxxxx> wrote:
>
>> Maybe I'm too nervous and actual implementation may be very simple.
>> But ACPI does allow above condition.
>
>Yes, I hadn't thought of the possibility of local variables being modified
>in the \_GPE.xxx method. Yuk.
>
>There are other problems relying on the kernel to notify us. For a start,
>an
>unpinned dom0 kernel is likely to get very confused about CPU APIC IDs
>and
>hence map processor objects incorrectly onto physical cpus, and quite
>possibly fail to register some processor objects entirely. That whole area
>is a mess without vcpu pinning (not something we want to rely on). This
>also
>means that having C-states controlled from dom0 kernel (no userland
>program
>at all) has similar limitation.
Yes, dom0 may not summarize same information as on native if it lacks
of correct knowledge to the environment, unless we change dom0 logic.
>Can we rely on from-scratch evaluation of DSDT and SSDTs to get us
>up-to-date C-state info? Perhaps we could trigger that via infrequent
>polling or some suitable low-level event (e.g., SCI count going up in
>/proc/interrupts)? Or could we be confident that evaluating the
>appropriate
>\_GPE.xxx object would be idempotent and hence safe to do from dom0
>userspace? Then we could always evaluate it before _CST.
I don't think so. ACPI content is BIOS/OEM specific, and we can't make
assumption here unless we analyze them and list only supported
BIOS/platforms (definitely not what we want)
>
>It's also possible that we should implement something simple, and then
>complicate it just as much as we need to based on testing on real
>systems.
>:-) Otherwise we tie ourselves in knots for cases that may not exist. So
>I'd
>be happy to start with one-shot static C-state determination from dom0
>userspace. That can always be disabled if it causes trouble on some
>systems,
>and be incrementally improved.
>
Agree on this suggestion. Actually I really can't come up reason why
available C-states may change especially on server platform. :-)
Thanks,
Kevin
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home