Seems like this is a regression bug in the kernel:
I installed linux-{image,ubuntu-modules}-2.6.24-28-xen from Ubuntu 8.04 and
cpufreq=dom0-kernel worked exactly as expected (i.e. the Dom0 kernel does
cpufreq scaling in exactly the same way it would if it were running natively).
I also tried
2.6.38 fixes it and cpufreq scaling works as expected.
As I did not find a precompiled 2.6.38 Dom0 kernel, I just took
linux-image-2.6.38-1-amd64 from sid (obviously that one lacks the Dom0 backend
drivers for supporting DomUs, but it is still capable of running as a Xen Dom0
by itself - so
On Fri, 2011-03-25 at 15:08 +0100, Michael Kuron wrote:
cpufreq=dom0-kernel
Oh, I wasn't aware that was an option. But as the note says, it only
works if you set a 1-to-1 mapping between physical CPUs and vCPUs in
dom0.
The 1-to-1 mapping is set using the dom0_vcpu_pin option,
Package: xen-linux-system-2.6.32-5-xen-amd64
Version: 2.6.32-31
Severity: normal
When booting the 2.6.32-5-xen-amd64 kernel natively, CPU frequency scaling
works as
expected: after installing cpufrequtils, the CPU clocks down as it should and
tools
like powertop show the CPU's P-states.
When
Thanks for your reply.
I know that Dom0 is virtualized too, but
http://wiki.xensource.com/xenwiki/xenpm seems to suggest that the
cpufreq=dom0-kernel Xen boot option allows you to do cpufreq scaling from the
Dom0: Domain0 based cpufreq reuse the domain0 kernel cpufreq code and let
domain0
On Fri, 2011-03-25 at 14:22 +0100, Michael Kuron wrote:
Thanks for your reply.
I know that Dom0 is virtualized too, but
http://wiki.xensource.com/xenwiki/xenpm seems to suggest that the
cpufreq=dom0-kernel Xen boot option allows you to do cpufreq scaling
from the Dom0: Domain0 based cpufreq
I've also tried cpufreq=xen (where the hypervisor is supposed to do
cpufreq scaling), but that didn't work either as the xenpm command
didn't appear to be able to do anything.
Why do you think that?
Nevermind, I just gave it another try (on the Intel box) and it does work,
xenpm
7 matches
Mail list logo