[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [RFC PATCH] Exporting ACPI Pxx/Cxx states to other kernel subsystems (v1).



Hello,

The following patches are a solution to a problem we have encountered
when using the Xen hypervisor:
 - Need Pxx/Cxx states to save on power consumption when using Xen (we
   do want those datacenters to consume less power!),
 - Also need to figure out the Turbo mode so that the scheduler can properly
   boost a core for CPU bound guests.

In essence the Xen hypervisor requires that information to work efficiently.

There are some other ways of solving this problem as well that have
been tossed around. I am enumerating them here, but I don't have the
full records of the disadvantages/advantges so hopefully some other people
can chime in.
 - Parse the information in userspace. I am not really sure how that would
   work, but one thought was export in SysFS the Pxx/Cxx states and other ones
   (hand-waving here) and the libvirt/xend/xl toolstack would parse those as
   needed and push them up (say when the guest is started). But it does have
   a disadvantage that it would not work well with CPU hotplug, nor with the
   physical CPU != virtual CPU discountinty (that is Linux sees only one CPU,
   and the ACPI Pxx says there are eight of them - with different values than
   the CPU0).
 - Make the ACPI subsystem export some of this functionality so that there
   can be multiple ACPI processor drivers and they can share common code.
   This is what this patch series follows. This does mean exporting some
   ACPI "stuff" outside drivers/acpi. 
 - Implement the ACPI DSDT parsing in the hypervisor. The couple of reasons
   that pop in my head for not going that route is foremost it seems an
   overkill just so that this specific information (Pxx/Cxx) can pushed in
   the hypervisor.  We already use the Linux ACPI to figure out the IRQ routing,
   or for ACPI states changes like button pushing, docking events, etc.
   Making it all be done in the hypervisor seems well, an overkill.

The original authors of the code are Intel folks. Liang has been working
on this to see if the abstraction can be improved, but I am by no means
an ACPI expert - so feedback, guidance or input would be much appreciated.


Liang:
 ACPI: processor: Don't setup cpu idle driver and handler

I think it can be actually dropped - now that disable_cpuidle() functionality
exists and we use it? 

Kevin Tian (6):
      ACPI: processor: export necessary interfaces
      ACPI: processor: cache acpi_power_register in cx structure
      ACPI: processor: Don't setup cpu idle driver and handler when we do not 
want them.
      ACPI: add processor driver for Xen virtual CPUs.
      ACPI: xen processor: add PM notification interfaces.
      ACPI: xen processor: set ignore_ppc to handle PPC event for Xen vcpu.

Tang Liang (2):
      ACPI: processor: add __acpi_processor_[un]register_driver helpers.
      ACPI: processor: override the interface of register acpi processor 
handler for Xen vcpu

 drivers/acpi/Makefile            |    1 +
 drivers/acpi/processor_driver.c  |   48 +++++--
 drivers/acpi/processor_idle.c    |   10 +-
 drivers/acpi/processor_perflib.c |    6 +-
 drivers/acpi/processor_xen.c     |  246 ++++++++++++++++++++++++++++++++++
 drivers/xen/Kconfig              |    5 +
 drivers/xen/Makefile             |    3 +
 drivers/xen/acpi_processor.c     |  269 ++++++++++++++++++++++++++++++++++++++
 include/acpi/processor.h         |   20 +++-
 include/xen/acpi.h               |  104 +++++++++++++++
 10 files changed, 690 insertions(+), 22 deletions(-)

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.