Re: Workings/effectiveness of the xen-acpi-processor driver

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

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). Which
> was not very successful as the drivers bail out of the init function because the
> 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
frequency scalling?

      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@2.67GHz) which was
> successfully loading the driver. Via xenpm I can see the various frequencies and
> 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 [00000000000000000001]
>                        residency  [00000000000000005398 ms]
> C1                   : transition [00000000000000000001]
>                        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

Yes. 
> 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 power
> 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
C0-C2.

"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 was
> 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.

> 
> Thanks,
> Stefan
>