>>> On 25.02.12 at 01:21, Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote: > But cpufreq != cpuidle != cpufreq governor, and they all are run by > different rules. > The ondemand cpufreq governor for example runs a timer and calls the > appropiate cpufreq > driver. So with these patches I posted we end up with a cpufreq driver in > the kernel > and in Xen hypervisor - both of them trying to change Pstates. Not good (to > be fair, > if powernow-k8/acpi-cpufreq would try it via WRMSR - those would up being > trapped and > ignored by the hypervisor. I am not sure about the outw though). I'm not aware of any trapping that would be done on the I/O port here; it could be added, though (i.e. the ports removed from the list of allowed ports of Dom0 once they become known to the hypervisor). > The pre-RFC version of this posted driver implemented a cpufreq governor that > was > nop and for future work was going to make a hypercall to get the true > cpufreq value > to report properly in /proc/cpuinfo - but I hadn't figured out a way to make > it be > the default one dynamically. > > Perhaps having xencommons do > echo "xen" > /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor > > And s/processor-passthru/cpufreq-xen/ would do it? That would eliminate the > [performance, > ondemand,powersave,etc] cpufreq governors from calling into the cpufreq > drivers to alter P-states. Except that you want this to be a cpufreq driver, not a governor. Jan -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
