On 08.08.10 19:08, Jukka Ruohonen wrote: > On Sun, Aug 08, 2010 at 04:58:42PM +0000, Jukka Ruohonen wrote: >> Merge P-state support for acpicpu(4). > > Hi. > > I'll post this note about conclusions from various informal discussions > regarding acpicpu(4) and CPU power management generally. > > In my opinion, it is increasingly evident that we will need a well-defined, > machine-independent interface and KPI especially for CPU frequency > management. I am very much willing to work with such a KPI, but the goal > here has been to first get the ACPI implementation ready, as a stand-alone > and modular component with minimal changes to existing MD code. > > There is still much work to do with the ACPI CPU driver. But once it is > ready and robust, we can continue to evaluate how much of this is > x86-specific, what would be the API requirements, what potential efficiency > concerns need to be taken into account, how CPU power management might be > driven by the scheduler, and so forth. > > So the MD things done here are more or less kludges to patch up things that > were already more or less kludges. The existing PowerNow! and EST need to > be eventually rewritten from scratch. The backwards compatibility need to > broken at some point. The sysctl(8) solution and user space "governors" > need to be deprecated to reach the full potential of modern CPU power > management on x86 and presumably on other architectures as well.
I want to bring up the way to go for Xen: A Xen guest (both Dom0 and DomU) only see virtual cpus. Only the hypervisor itself see the physical cpus. Hence the C- and P-State handling must be done through hypercalls. The hypercalls are for Dom0 only. The hypervisor informs Dom0 via events about the physical cpu frequencies so that Dom0 has a chance to react when changes happen. Christoph
