From: arjan@linux.intel.com
To: linux-pm@vger.kernel.org
Cc: artem.bityutskiy@linux.intel.com, rafael@kernel.org,
Arjan van de Ven <arjan@linux.intel.com>
Subject: [PATCH 00/7 Add support for running in VM guests to intel_idle
Date: Thu, 1 Jun 2023 18:27:54 +0000 [thread overview]
Message-ID: <20230601182801.2622044-1-arjan@linux.intel.com> (raw)
From: Arjan van de Ven <arjan@linux.intel.com>
intel_idle provides the CPU Idle states (for power saving in idle) to the
cpuidle framework, based on per-cpu tables combined with limited hardware
enumeration. This combination of cpuidle and intel_idle provides dynamic
behavior where power saving and performance impact are dynamically balanced
and where a set of generic knobs are provided in sysfs for users to tune
the heuristics (and get statistics etc)
However, intel_idle currently does not support running inside VM guests, and
the linux kernel falls back to either ACPI based idle (if supported by the
hypervisor/virtual bios) or just the default x86 fallback "hlt" based idle
method... that was introduced in the 1.2 kernel series... and lacks all the
dynamic behavior, user control and statistics that cpuidle brings.
While this is obviously functional, it's not great and we can do better
for the user by hooking up intel_idle into the cpuidle framework also
for the "in a guest" case.
And not only not great for the user, it's also not optimal and lacks two
key capabilities that are supported by the bare metal case:
1) The ability to flush the TLB for very long idle periods, to avoid
a costly (and high latency) IPI wakeup later, of an idle vCPU when a
process that used to run on the idle vCPU does an munmap or similar
operation. Avoiding high latency IPIs helps avoid performance jitter.
2) The ability to use the new Intel C0.2 idle state instead of polling
for very short duration idle periods to save power (and carbon footprint)
This patch series adds the basic support to run in a VM guest
to the intel_idle driver, and then addresses the first of these shortfalls.
The C0.2 gap will be fixed with a small additional patch after the
C0.2 support is merged seperately.
Arjan van de Ven (7):
intel_idle: refactor state->enter manipulation into its own function
intel_idle: clean up the (new) state_update_enter_method function
intel_idle: Add a sanity check in the new state_update_enter_method
function
intel_idle: Add helper functions to support 'hlt' as idle state
intel_idle: Add a way to skip the mwait check on all states
intel_idle: Add support for using intel_idle in a VM guest using just
hlt
intel_idle: Add a "Long HLT" C1 state for the VM guest mode
drivers/idle/intel_idle.c | 216 ++++++++++++++++++++++++++++++++++----
1 file changed, 194 insertions(+), 22 deletions(-)
--
2.40.1
next reply other threads:[~2023-06-01 18:30 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-01 18:27 arjan [this message]
2023-06-01 18:27 ` [PATCH 1/7] intel_idle: refactor state->enter manipulation into its own function arjan
2023-06-01 18:27 ` [PATCH 2/7] intel_idle: clean up the (new) state_update_enter_method function arjan
2023-06-04 15:34 ` Rafael J. Wysocki
2023-06-04 22:35 ` Van De Ven, Arjan
2023-06-01 18:27 ` [PATCH 3/7] intel_idle: Add a sanity check in the new " arjan
2023-06-04 15:43 ` Rafael J. Wysocki
2023-06-01 18:27 ` [PATCH 4/7] intel_idle: Add helper functions to support 'hlt' as idle state arjan
2023-06-04 15:46 ` Rafael J. Wysocki
2023-06-01 18:27 ` [PATCH 5/7] intel_idle: Add a way to skip the mwait check on all states arjan
2023-06-04 15:54 ` Rafael J. Wysocki
2023-06-05 15:24 ` Arjan van de Ven
2023-06-01 18:28 ` [PATCH 6/7] intel_idle: Add support for using intel_idle in a VM guest using just hlt arjan
2023-06-04 15:59 ` Rafael J. Wysocki
2023-06-04 22:34 ` Van De Ven, Arjan
2023-06-01 18:28 ` [PATCH 7/7] intel_idle: Add a "Long HLT" C1 state for the VM guest mode arjan
2023-06-04 15:01 ` [PATCH 00/7 Add support for running in VM guests to intel_idle Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230601182801.2622044-1-arjan@linux.intel.com \
--to=arjan@linux.intel.com \
--cc=artem.bityutskiy@linux.intel.com \
--cc=linux-pm@vger.kernel.org \
--cc=rafael@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).