From: Christian Loehle <christian.loehle@arm.com>
To: "Ionut Nechita (Sunlight Linux)" <sunlightlinux@gmail.com>,
rafael@kernel.org
Cc: ionut_n2001@yahoo.com, daniel.lezcano@linaro.org,
linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 0/1] cpuidle: menu: Fix high wakeup latency on modern Intel server platforms
Date: Wed, 21 Jan 2026 11:49:19 +0000 [thread overview]
Message-ID: <eac3541b-f22f-4cd9-a31e-4841e4fad5a1@arm.com> (raw)
In-Reply-To: <20260120211725.124349-1-sunlightlinux@gmail.com>
On 1/20/26 21:17, Ionut Nechita (Sunlight Linux) wrote:
> From: Ionut Nechita <ionut_n2001@yahoo.com>
>
> Hi,
Hi Ionut,
>
> This patch addresses a performance regression in the menu cpuidle governor
> affecting modern Intel server platforms (Sapphire Rapids, Granite Rapids,
> and newer).
I'll take a look at the patch later, but just to be clear, this isn't a
performance regression right? There's no kernel version that this behaved
better with, is there?
If there is it needs to be stated and maybe a Fixes tag would be applicable.
>
> == Problem Description ==
>
> On Intel server platforms from 2022 onwards, we observe excessive wakeup
> latencies (~150us) in network-sensitive workloads when using the menu
> governor with NOHZ_FULL enabled.
>
> Measurement with qperf tcp_lat shows:
> - Sapphire Rapids (SPR): 151us latency
> - Ice Lake (ICL): 12us latency
> - Skylake (SKL): 21us latency
>
> The 12x latency regression on SPR compared to Ice Lake is unacceptable for
> latency-sensitive applications (HPC, real-time, financial trading, etc.).
So just newer generation having higher latency.
TBF the examples you mentioned should really have their latencies in control
themselves and not rely on menu guesstimating what's needed here.
>
> == Root Cause ==
>
> The issue stems from menu.c:294-295:
>
> if (tick_nohz_tick_stopped() && predicted_ns < TICK_NSEC)
> predicted_ns = data->next_timer_ns;
>
> When the tick is already stopped and the predicted idle duration is short
> (<2ms), the governor switches to using next_timer_ns directly (often
> 10ms+). This causes the selection of very deep package C-states (PC6).
>
> Modern server platforms have significantly longer C-state exit latencies
> due to architectural changes:
> - Tile-based architecture with per-tile power gating
> - DDR5 power management overhead
> - CXL link restoration
> - Complex mesh interconnect resynchronization
>
> When a network packet arrives after 500us but the governor selected PC6
> based on a 10ms timer, the 150us exit latency dominates the response time.
>
> On older platforms (Ice Lake, Skylake) with faster C-state transitions
> (12-21us), this issue was less noticeable, but SPR's tile architecture
> makes it critical.
> [snip]
Can you provide idle state tables with residencies and usage?
Ideally idle misses for both as well?
Thanks!
next prev parent reply other threads:[~2026-01-21 11:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-20 21:17 Ionut Nechita (Sunlight Linux)
2026-01-20 21:17 ` [PATCH 1/1] cpuidle: menu: Add 25% safety margin to short predictions when tick is stopped Ionut Nechita (Sunlight Linux)
2026-01-21 11:55 ` Christian Loehle
2026-01-21 11:49 ` Christian Loehle [this message]
2026-01-21 22:42 ` [PATCH 0/1] cpuidle: menu: Fix high wakeup latency on modern Intel server platforms Russell Haley
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=eac3541b-f22f-4cd9-a31e-4841e4fad5a1@arm.com \
--to=christian.loehle@arm.com \
--cc=daniel.lezcano@linaro.org \
--cc=ionut_n2001@yahoo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=sunlightlinux@gmail.com \
/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®