[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH] 1/2: cpufreq/PowerNow! in Xen: Time and platform changes
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. 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. 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. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |