[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1322673664-14642-1-git-send-email-konrad.wilk@oracle.com>
Date: Wed, 30 Nov 2011 12:20:56 -0500
From: Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>
To: ke.yu@...el.com, kevin.tian@...el.com,
linux-kernel@...r.kernel.org, linux-acpi@...r.kernel.org,
lenb@...nel.org, rjw@...k.pl
Cc: xen-devel@...ts.xensource.com, jeremy@...p.org, konrad@...nel.org,
stefan.bader@...onical.com, Ian.Campbell@...rix.com,
mike.mcclurg@...rix.com, liang.tang@...cle.com
Subject: [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(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists