[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver
On Wed, Apr 25, 2012 at 03:00:58PM +0200, Stefan Bader wrote:
> Since there have been requests about that driver to get backported into 3.2, I
> was interested to find out what or how much would be gained by that.
> The first system I tried was an AMD based one (8 core Opteron 6128@2GHz).
> was not very successful as the drivers bail out of the init function because
> first call to acpi_processor_register_performance() returns -ENODEV. There is
> some frequency scaling when running without Xen, so I need to do some more
> debugging there.
Did you back-port the other components - the ones that turn off the native
provide disable_cpufreq() function to disable the API.
xen/acpi-processor: Do not depend on CPU frequency scaling drivers.
xen/cpufreq: Disable the cpu frequency scaling drivers from loading
> The second system was an Intel one (4 core i7 920@xxxxxxx) which was
> successfully loading the driver. Via xenpm I can see the various frequencies
> also see them being changed. However the cpuidle data out of xenpm looks a
> bit odd:
> #> xenpm get-cpuidle-states 0
> Max C-state: C7
> cpu id : 0
> total C-states : 2
> idle time(ms) : 10819311
> C0 : transition 
> residency [00000000000000005398 ms]
> C1 : transition 
> residency [00000000000010819311 ms]
> pc3 : [00000000000000000000 ms]
> pc6 : [00000000000000000000 ms]
> pc7 : [00000000000000000000 ms]
> cc3 : [00000000000000000000 ms]
> cc6 : [00000000000000000000 ms]
> Also gathering samples over 30s does look like only C0 and C1 are used. This
> might be because C1E support is enabled in BIOS but when looking at the
> intel_idle data in sysfs when running without a hypervisor will show C3 and C6
> for the cores. That could have been just a wrong output, so I plugged in a
> meter and compared a kernel running natively and running as dom0 (with and
> without the acpi-processor driver).
> Native: 175W
> dom0: 183W (with only marginal difference between with or without the
> processor driver)
> [yes, the system has a somewhat high base consumption which I attribute to a
> ridiculously dimensioned graphics subsystem to be running a text console]
> This I would take as C3 and C6 really not being used and the frequency scaling
To go in deeper modes there is also a need to backport a Xen unstable
hypercall which will allow the kernel to detect the other states besides
"XEN_SET_PDC query was implemented in c/s 23783:
"ACPI: add _PDC input override mechanism".
> having no impact on the idle system is not that much surprising. But if that
> true it would also limit the usefulness of the turbo mode which I understand
> would also be limited by the c-state of the other cores.
Hm, I should double-check that - but somehow I thought that Xen independetly
checks for TurboMode and if the P-states are in, then they are activated.
> Do I misread the data I see? Or maybe its a known limitation? In case it is
> worth doing more research I'll gladly try things and gather more data.
Just missing some patches.
Oh, and this one:
xen/acpi: Fix Kconfig dependency on CPU_FREQ
Hmm.. I think a patch disappeared somewhere.
Xen-devel mailing list