Re: [Xen-devel] Workings/effectiveness of the xen-acpi-processor driver

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Thu, Apr 26, 2012 at 06:25:28PM +0200, Stefan Bader wrote:
> On 26.04.2012 17:50, Konrad Rzeszutek Wilk wrote:
> > 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
> >>
> 
> Yes, here is the full set for reference:
> 
> * xen/cpufreq: Disable the cpu frequency scaling drivers from loading.
> * xen/acpi: Remove the WARN's as they just create noise.
> * xen/acpi: Fix Kconfig dependency on CPU_FREQ
> * xen/acpi-processor: Do not depend on CPU frequency scaling drivers.
> * xen/acpi-processor: C and P-state driver that uploads said data to hyper
> * provide disable_cpufreq() function to disable the API.

The one thing that I forgot to mention about the:
 xen/cpufreq: Disable the cpu frequency scaling drivers from loading.

is that it also fixes a bug - which is that without this, the acpi-cpufreq
would run and change the frequency states based on what dom0 thought was good.
Which meant that Xen hypervisor would run with somebody behind its back
changing the P-states - and would lower the performance in some case
a lot (especially if one used the dom0_max_vcpus=X).
.. snip..
> >> Native: 175W
> >> dom0:   183W (with only marginal difference between with or without the
> >>               processor driver)

What happens if you run it xen-acpi-processor.off=1 ?

(That should inhibit the driver from uploading the power management data).

Is the value ~200w?

> >> [yes, the system has a somewhat high base consumption which I attribute to 
> >> a
> >> ridiculously dimensioned graphics subsystem to be running a text console]

Heh.
> >>
> >> 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".
> >     
> 
> I see. There is a kernel patch about enabling MWAIT that refers to that...

Yeah, I should see about back-porting it in Xen 4.1..

> 
> > 
> >> 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.
> > 
> Turbo mode should be enabled. I had been only looking at a generic overview
> about it on Intel site which sounded like it  would make more of a difference 
> on
> how much one core could get overclocked related to how many cores are active
> (and I translated active or not into deeper c-states or not).
> Looking at the verbose output of turbostat it seems not to make that much
> difference whether 2-4 cores are running. A single core alone could get one 
> more
> increment in clock stepping. That does not immediately sound a lot. And of
> course how much or long the higher clock is used depends on other factors as
> well and is not under OS control.
> 
> In the end it is probably quite dynamic and hard to come up with hard facts to
> prove its value. Though if I can lower the idle power usage by reaching a bit
> further, that would greatly help to justify the effort and potential risk of
> backporting...

Did you see the P-states dipping? I don't really know how much using C-states
beyond C-2 matters on baremetal in terms of saving power?

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

This patchset was driven more by the performance needs. Somehow (and I am not
sure how), using the PM, makes the whole system work much faster. That was
what Ian found out when he ran the Phorenix benchmark.

But looking back, perhaps the reason for this was that the native
cpufreq scaling drivers were running in the back changing the machine's
power states without consulting the Xen hypervisor.

> > 
> > 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
> >>
> > 
> > 
> > 
> > _______________________________________________
> > Xen-devel mailing list
> > Xen-devel@xxxxxxxxxxxxx
> > http://lists.xen.org/xen-devel
> 
> 



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel