Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian Kernel (http://www.linux-archive.org/debian-kernel/)
-   -   Bug#619573: xen-linux-system-2.6.32-5-xen-amd64: cpufreq scaling in Dom0 does not work (http://www.linux-archive.org/debian-kernel/505433-bug-619573-xen-linux-system-2-6-32-5-xen-amd64-cpufreq-scaling-dom0-does-not-work.html)

Michael Kuron 03-25-2011 08:53 AM

Bug#619573: xen-linux-system-2.6.32-5-xen-amd64: cpufreq scaling in Dom0 does not work
 
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 booting the kernel as Dom0 on Xen 4.0.1 however, messages like
> [ 15.778182] powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor
> 4800+ processors (2 cpu cores) (version 2.20.00)
> [ 15.778195] [Firmware Bug]: powernow-k8: No compatible ACPI _PSS objects
> found.
> [ 15.778197] [Firmware Bug]: powernow-k8: Try again with latest BIOS.
are logged upon boot, suggesting that Xen somehow prevents the kernel from accessing
the P-states ACPI objects and as a result, cpufrequtils fail to start:
> CPUFreq Utilities: Setting ondemand CPUFreq governor...disabled, governor
> not available...done.
and the CPU does not clock down.

Adding cpufreq=dom0-kernel to the xen.gz line in my Grub2 config does not help, and
adding dom0_vcpus_pin (which as far as I can tell from the Xen source is implied by
cpufreq=dom0-kernel anyway) and/or cpuidle does not make a difference either.
cpufreq=xen is not supported on the AMD K8 system and does not fix the issue on the
Intel either (xenpm get-cpufreq-states still doesn't show anything).

I observed this on both an AMD Athlon 64 X2 (K8 family), which uses the powernow-k8.ko
module, and an Intel Pentium D, which uses the acpi-cpufreq.ko module.
Both systems supply their _PSS objects using the SSDT. Out of curiosity, on the AMD
system, I decompiled both the DSDT and SSDT and manually merged the _PSS sections into
the DSDT. I then injected it using Grub2's acpi command, but it didn't make any
difference, suggesting that it has nothing to do with which table the objects are stored
in.

Also, manually dumping the tables from /sys/firmware/acpi/tables/* looks exactly the
same both in Dom0 mode and natively, suggesting that Xen doesn't actually touch the ACPI
tables, but rather the cpufreq kernel module fails to look in the right spot.

-- System Information:
Debian Release: 6.0.1
APT prefers squeeze-updates
APT policy: (500, 'squeeze-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32-5-xen-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Versions of packages xen-linux-system-2.6.32-5-xen-amd64 depends on:
ii linux-image-2.6.32-5-xen-amd6 2.6.32-31 Linux 2.6.32 for 64-bit PCs, Xen d
ii xen-hypervisor-4.0-amd64 [xen 4.0.1-2 The Xen Hypervisor on AMD64

xen-linux-system-2.6.32-5-xen-amd64 recommends no packages.

xen-linux-system-2.6.32-5-xen-amd64 suggests no packages.

-- no debconf information



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110325095347.1768.95961.reportbug@mkuron-pc.home.kuron-germany.de">http://lists.debian.org/20110325095347.1768.95961.reportbug@mkuron-pc.home.kuron-germany.de

"Michael Kuron" 03-25-2011 12:22 PM

Bug#619573: xen-linux-system-2.6.32-5-xen-amd64: cpufreq scaling in Dom0 does not work
 
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 handle the cpufreq logic".
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.

Am I getting something completely wrong here? If so, what is the correct way for enabling cpufreq scaling on a Xen system?

On 25.03.2011, at 13:45, Debian Bug Tracking System wrote:
> Well, yes. dom0 works with *virtual* CPUs. Any physical CPU frequency
> scaling must be done by the hypervisor.


--
GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
gratis Handy-Flat! http://portal.gmx.net/de/go/dsl



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110325132227.52150@gmx.net">http://lists.debian.org/20110325132227.52150@gmx.net

Ben Hutchings 03-25-2011 12:46 PM

Bug#619573: xen-linux-system-2.6.32-5-xen-amd64: cpufreq scaling in Dom0 does not work
 
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 reuse the domain0 kernel cpufreq
> code and let domain0 handle the cpufreq logic".

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.

> 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?

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

"Michael Kuron" 03-25-2011 01:08 PM

Bug#619573: xen-linux-system-2.6.32-5-xen-amd64: cpufreq scaling in Dom0 does not work
 
> > 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 get-cpufreq-para actually produces the expected output now and the CPU appears to scale down.


> > 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, which is implied by the cpufreq=dom0-kernel option (taken from xen-4.0.1/xen/common/domain.c:setup_cpufreq_option):
if ( !strcmp(str, "dom0-kernel") )
{
xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
cpufreq_controller = FREQCTL_dom0_kernel;
opt_dom0_vcpus_pin = 1;
return;
}


The cpufreq=dom0-kernel option is what I am actually interested in because cpufreq=xen is not supported on older AMD CPUs. However, I have not been able to actually get it to work yet.
--
NEU: FreePhone - kostenlos mobil telefonieren und surfen!
Jetzt informieren: http://www.gmx.net/de/go/freephone



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110325140856.256320@gmx.net">http://lists.debian.org/20110325140856.256320@gmx.net

Ben Hutchings 03-26-2011 03:53 PM

Bug#619573: xen-linux-system-2.6.32-5-xen-amd64: cpufreq scaling in Dom0 does not work
 
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, which is
> implied by the cpufreq=dom0-kernel option (taken from
> xen-4.0.1/xen/common/domain.c:setup_cpufreq_option):
> if ( !strcmp(str, "dom0-kernel") )
> {
> xen_processor_pmbits &= ~XEN_PROCESSOR_PM_PX;
> cpufreq_controller = FREQCTL_dom0_kernel;
> opt_dom0_vcpus_pin = 1;
> return;
> }
>
>
> The cpufreq=dom0-kernel option is what I am actually interested in
> because cpufreq=xen is not supported on older AMD CPUs. However, I
> have not been able to actually get it to work yet.

OK, I'm reopening the bug, but I'm afraid I'm not likely to spend time
investigating it.

Ben.

--
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.

"Michael Kuron" 03-27-2011 10:32 AM

Bug#619573: xen-linux-system-2.6.32-5-xen-amd64: cpufreq scaling in Dom0 does not work
 
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 linux-{image,modules}-2.6.26-2-xen-amd64 from Debian Lenny, but unfortunately that one lacks the cpufreq modules.

Apparently, the bug was introduced somewhere between 2.6.25 and 2.6.31: http://lists.xensource.com/archives/html/xen-devel/2010-02/msg00354.html

Which other kernel versions should I test to help narrow this down?

> > The cpufreq=dom0-kernel option is what I am actually interested in
> > because cpufreq=xen is not supported on older AMD CPUs. However, I
> > have not been able to actually get it to work yet.
>
> OK, I'm reopening the bug, but I'm afraid I'm not likely to spend time
> investigating it.
--
GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
gratis Handy-Flat! http://portal.gmx.net/de/go/dsl



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110327103250.25900@gmx.net">http://lists.debian.org/20110327103250.25900@gmx.net

"Michael Kuron" 03-27-2011 01:41 PM

Bug#619573: xen-linux-system-2.6.32-5-xen-amd64: cpufreq scaling in Dom0 does not work
 
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 e.g. xm dmesg shows clearly that the kernel is running on the hypervisor, but xm create fails due to missing kernel support).

So the bug was introduced somewhere between 2.6.25 and 2.6.31 and fixed somewhere between 2.6.33 and 2.6.38.

> 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 linux-{image,modules}-2.6.26-2-xen-amd64 from Debian Lenny,
> but unfortunately that one lacks the cpufreq modules.
--
NEU: FreePhone - kostenlos mobil telefonieren und surfen!
Jetzt informieren: http://www.gmx.net/de/go/freephone



--
To UNSUBSCRIBE, email to debian-kernel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20110327134152.309430@gmx.net">http://lists.debian.org/20110327134152.309430@gmx.net


All times are GMT. The time now is 11:29 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.