From: Christian Loehle <christian.loehle@arm.com>
To: Breno Leitao <leitao@debian.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
kernel-team@meta.com
Subject: Re: [PATCH] cpuidle: menu: Remove incorrect unlikely() annotation
Date: Mon, 5 Jan 2026 15:17:05 +0000 [thread overview]
Message-ID: <73439919-e24d-4bd5-a7ed-d7633beb5e4f@arm.com> (raw)
In-Reply-To: <20260105-annotated_idle-v1-1-10ddf0771b58@debian.org>
On 1/5/26 14:37, Breno Leitao wrote:
> The unlikely() annotation on the early-return condition in menu_select()
> is incorrect on systems with only one idle state (e.g., ARM64 servers
> with a single ACPI LPI state). Branch profiling shows 100% misprediction
> on such systems since drv->state_count <= 1 is always true.
>
> On platforms where only state0 is available, this path is the common
> case, not an unlikely edge case. Remove the misleading annotation to
> let the branch predictor learn the actual behavior.
>
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
> drivers/cpuidle/governors/menu.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c
> index 64d6f7a1c776..ef9c5a84643e 100644
> --- a/drivers/cpuidle/governors/menu.c
> +++ b/drivers/cpuidle/governors/menu.c
> @@ -271,7 +271,7 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev,
> data->bucket = BUCKETS - 1;
> }
>
> - if (unlikely(drv->state_count <= 1 || latency_req == 0) ||
> + if (drv->state_count <= 1 || latency_req == 0 ||
> ((data->next_timer_ns < drv->states[1].target_residency_ns ||
> latency_req < drv->states[1].exit_latency_ns) &&
> !dev->states_usage[0].disable)) {
>
> ---
> base-commit: 34aa263125b6732375abcb908d73d98169154bb5
> change-id: 20260105-annotated_idle-d6b614ecd207
>
> Best regards,
> --
> Breno Leitao <leitao@debian.org>
>
>
Fine with me per se, I don't think the unlikely() annotation makes a
difference for the 'good case' either, but if you run into this I'd be curious
if you can see a difference with menu (which should stop the tick on every idle enter
regardless) and teo (which should never stop the tick on state_count == 1).
Alternative you can also just change the menu branch to not stop the tick.
I'd like to know if we need something more sophisticated generally here.
next prev parent reply other threads:[~2026-01-05 15:17 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-05 14:37 Breno Leitao
2026-01-05 15:17 ` Christian Loehle [this message]
2026-01-05 16:41 ` Breno Leitao
2026-01-09 20:54 ` 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=73439919-e24d-4bd5-a7ed-d7633beb5e4f@arm.com \
--to=christian.loehle@arm.com \
--cc=daniel.lezcano@linaro.org \
--cc=kernel-team@meta.com \
--cc=leitao@debian.org \
--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
all inboxes | Powered by JetHome®