From: Christian Loehle <christian.loehle@arm.com>
To: Aboorva Devarajan <aboorvad@linux.ibm.com>,
rafael@kernel.org, daniel.lezcano@linaro.org,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: gautam@linux.ibm.com
Subject: Re: [PATCH 1/1] cpuidle/menu: avoid prioritizing physical state over polling state
Date: Thu, 19 Sep 2024 17:08:15 +0100 [thread overview]
Message-ID: <6c6ef251-814d-45c8-bbad-3096b9265397@arm.com> (raw)
In-Reply-To: <20240809073120.250974-2-aboorvad@linux.ibm.com>
On 8/9/24 08:31, Aboorva Devarajan wrote:
> Update the cpuidle menu governor to avoid prioritizing physical states
> over polling states when predicted idle duration is lesser than the
> physical states target residency duration for performance gains.
I would use something like this as wording:
[PATCH] cpuidle: menu: Select polling on short predicted idle
Select a shallow state matching our predicted_ns even if it is a
polling one.
Additionally to querying the next timer event, menu also employs an
interval tracking strategy of most recent idle durations for workloads
that aren't woken up by predictable timer events. The logic predicts
the next wakeup as predicted_ns, but the logic handling that skipped
any polling states.
In the worst-case on POWER we might only have snooze as polling and
CEDE. This makes the entire logic around it a NOP as it never let's
predicted_ns choose an appropriate idle state since it requires a
non-polling one.
To actually enforce predicted_ns for idle state selection actually use
states even though they are polling ones.
Even for a perfect recent intervals of
[1, 1, 1, 1, 1, 1, 1, 1]
menu previously chose the first non-idle state.
-----
To mitigate potential side-effects since most platforms have a
shallower idle state we could add something based on that, but
really your patch would be the only consistent IMO.
I'm not quite sure why this was put there in the first place.
It was essentially introduced in
commit ("69d25870f20c cpuidle: fix the menu governor to boost IO performance")
with a 20us lower limit.
>
> Signed-off-by: Aboorva Devarajan <aboorvad@linux.ibm.com>
> ---
> drivers/cpuidle/governors/menu.c | 11 -----------
> 1 file changed, 11 deletions(-)
>
> diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
> index f3c9d49f0f2a..cf99ca103f9b 100644
> --- a/drivers/cpuidle/governors/menu.c
> +++ b/drivers/cpuidle/governors/menu.c
> @@ -354,17 +354,6 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
> idx = i; /* first enabled state */
>
> if (s->target_residency_ns > predicted_ns) {
> - /*
> - * Use a physical idle state, not busy polling, unless
> - * a timer is going to trigger soon enough.
> - */
> - if ((drv->states[idx].flags & CPUIDLE_FLAG_POLLING) &&
> - s->exit_latency_ns <= latency_req &&
> - s->target_residency_ns <= data->next_timer_ns) {
> - predicted_ns = s->target_residency_ns;
> - idx = i;
> - break;
> - }
> if (predicted_ns < TICK_NSEC)
> break;
>
next prev parent reply other threads:[~2024-09-19 16:08 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-09 7:31 [PATCH 0/1] cpuidle/menu: Address performance drop from favoring physical over polling cpuidle state Aboorva Devarajan
2024-08-09 7:31 ` [PATCH 1/1] cpuidle/menu: avoid prioritizing physical state over polling state Aboorva Devarajan
2024-08-13 13:09 ` Christian Loehle
2024-09-19 16:08 ` Christian Loehle [this message]
2024-10-18 10:36 ` Gautam Menghani
2024-08-13 12:56 ` [PATCH 0/1] cpuidle/menu: Address performance drop from favoring physical over polling cpuidle state Christian Loehle
2024-08-20 8:51 ` Aboorva Devarajan
2024-08-21 10:55 ` Christian Loehle
2024-09-19 5:02 ` Aboorva Devarajan
2024-09-19 8:49 ` Christian Loehle
2024-09-19 9:43 ` Christian Loehle
2024-09-19 14:07 ` Christian Loehle
2024-09-19 14:38 ` Christian Loehle
2024-10-21 8:02 ` Aboorva Devarajan
2024-10-21 9:03 ` Christian Loehle
2024-10-21 7:40 ` Aboorva Devarajan
2024-10-21 5:27 ` Aboorva Devarajan
2024-10-21 8:43 ` Christian Loehle
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=6c6ef251-814d-45c8-bbad-3096b9265397@arm.com \
--to=christian.loehle@arm.com \
--cc=aboorvad@linux.ibm.com \
--cc=daniel.lezcano@linaro.org \
--cc=gautam@linux.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--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