From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 3EBF12D978B for ; Tue, 20 Jan 2026 21:17:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.48 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768943852; cv=none; b=VuYIHJvkckwt9CLraaX5ZlFCM1e0E+272Wo+/Ja4QrZSYDBRZrHnBiBTDu2HxogFCduvBp35bQPAOvlXk+IgSw7i9GecwdnizWF80Y9MkpFwjKY+5j/9toYCk/KcThaChyOZQo8F3PJabwWnc15Upw6YIblNZJKdzYyMoqFT1qs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768943852; c=relaxed/simple; bh=wSNBtjMm+V2IMmq80iy1SYwdosKesmUsLxmEQ8W4CfY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=cPJPL+86Rm6py8BHIik1TVRi38oWVTHQzwlPgzLT7niNKQWVh8gg7l56212TiExgZoiQ35Zld8OR6ZGlLf+qlq8y9n6os0yAskDo7BCjrC/dRDZAicEaRxq5QPipaYnlE3UP7Y8c2NfsYblN+XmZ2afnH5hKSlfqqumrF82LEKY= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=hhUUf0n9; arc=none smtp.client-ip=209.85.128.48 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="hhUUf0n9" Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-47ee0291921so40218875e9.3 for ; Tue, 20 Jan 2026 13:17:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1768943848; x=1769548648; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=GD+qh96BuStlVCr6m9cgS9Z50cJM3b7YbGlN1ubHWWY=; b=hhUUf0n917x45y0PUHXNQCb6JKigOyr7PIpiMiE/1W4vLvKLmAVVCO8c5rosGGZMAY xvyA4PoFchSNa59ayvA3aqhEX9uQroi1tRsFP/dLOoyPPVVk7xA0iJ8AGSEXlL40mdHd IhbMJsb2HEcT9/jgzkuiG/zHJ65GYiV2LozkMPI16t05Euz6biDNMichHhr1+EcHhGHK AaA0WSl4yEk3iYx/wFvwAPI/l4osEvDCKa6H6IVmGrjo2VN7D+wamNAPHxr/QDZtvGFA 7TUwWq44uBwUHv4T9nvQOj+k1sFq/y8J4AONng7KQ+WcSegnj3tVDALmGq7zuMtV89NM mCFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1768943848; x=1769548648; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=GD+qh96BuStlVCr6m9cgS9Z50cJM3b7YbGlN1ubHWWY=; b=bsuIgmU1DX8Air8hDaWhku+hQwE4KYzQ2DGLcIiq+s6p3ZjkkF4MfuqUc4E94b+7b7 vlvbs9CdvcL/e6M8DMT9XAbk0kUSxJKHY4CCkYwFly8zYzO7aaMPx3W3tQi+2ON7t2Ro jlOzwrqoM0i8VrWJrQIBwXckopGUMQygQeyQ/gK+CpTf2bB2UfAtcrN0LJvWpmtTJ2QW iN5hUTtOEoBJyLxf70x2frjtRfozwzPGmd18eEReq0G3+LNim9SLeMzctMNata85tNHB Z0etR6HxbcE3hpSsl7e00gOUdLcjie8+2PLHc8f2+7b/aZND3DTysRjcV+1Qz7P/II3z N38g== X-Forwarded-Encrypted: i=1; AJvYcCUB0ieSWIOYiXMeb1ZPQRduAFWQkqEJAtIxwCBOGJycxiGadvhpjX9OvG/4Ied0QIv/Ob5ok6DBIjzjNQE=@vger.kernel.org X-Gm-Message-State: AOJu0Yzh35mKX6iSDCh70UPh3grZgNaPRIwPuGODXPDxb9aqV0noDhei WERMo60xJ6kKJdgcJs4qYIiiiM9/EqbdHFsDc8QX/BXm1eLKXXomHJZY X-Gm-Gg: AY/fxX6o2tuSxyt4Foipwe1awNoiqhwzKwb7ccIfRAqejUKyYRihTY7480EsK3Jme2q iKO2p2AXtTmnuru7aAQaF1zXY80+tDA2vG5HzKCq25oY92S9ndL2a6Ds/PGXnoaEQYJun96Dnw0 j7s+4URolD64CNcKusxM2qiozEdkyt/bFOujH3cMChm8FJbFgfX8YwCvFKP806/v09cckVExDkJ n3WTRccXrtZFMj2zAeVZ4rEhpXXmu11CvFhTbBMWd3r6Od3pbJPul56PNMwr2bzHUOafSglJGeF U2oqr/wI0a/KEJTsVgazHENxte/TH9Qb1cNs2DlgH8Wu9W+H3PxEF8p20PAN3STqpnUF1qR+sti 0ZAmFS5en2vrhpoR7bqRKbDiHfSUjCl1ycqOfx9xtoJXhv5kGqJ3YLkxp9+2EYuLOR/7OSzdQZz 2pUM5P8sbhgtNnme21/iRsXBEcOX2CvD3MvWGn7sc= X-Received: by 2002:a05:600c:811a:b0:480:1dc6:2686 with SMTP id 5b1f17b1804b1-4801eac0cfcmr174219805e9.13.1768943848296; Tue, 20 Jan 2026 13:17:28 -0800 (PST) Received: from ionutnechita-arz2022.local ([2a02:2f0e:c504:d100:f54e:1a6b:fa97:f3ec]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-47f4b2672d6sm329104325e9.14.2026.01.20.13.17.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Jan 2026 13:17:28 -0800 (PST) From: "Ionut Nechita (Sunlight Linux)" To: rafael@kernel.org Cc: ionut_n2001@yahoo.com, daniel.lezcano@linaro.org, christian.loehle@arm.com, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: [PATCH 1/1] cpuidle: menu: Add 25% safety margin to short predictions when tick is stopped Date: Tue, 20 Jan 2026 23:17:25 +0200 Message-ID: <20260120211725.124349-2-sunlightlinux@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <20260120211725.124349-1-sunlightlinux@gmail.com> References: <20260120211725.124349-1-sunlightlinux@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: Ionut Nechita When the tick is already stopped and the predicted idle duration is short (< TICK_NSEC), the original code uses next_timer_ns directly. This can be too conservative on platforms with high C-state exit latencies. On Intel server platforms (2022+), this causes excessive wakeup latencies (~150us) when the actual idle duration is much shorter than next_timer_ns, because the governor selects package C-states (PC6) when shallower states would be more appropriate. Add a 25% safety margin to the prediction instead of using next_timer_ns directly, while still clamping to next_timer_ns to avoid selecting unnecessarily deep states. Testing shows this reduces qperf latency from 151us to ~30us on affected platforms while maintaining good power efficiency. Platforms with fast C-state transitions (Ice Lake: 12us, Skylake: 21us) see minimal impact. Cc: stable@vger.kernel.org Signed-off-by: Ionut Nechita --- drivers/cpuidle/governors/menu.c | 16 ++++++++++++---- 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/drivers/cpuidle/governors/menu.c b/drivers/cpuidle/governors/menu.c index 64d6f7a1c776..de1dd46fea7a 100644 --- a/drivers/cpuidle/governors/menu.c +++ b/drivers/cpuidle/governors/menu.c @@ -287,12 +287,20 @@ static int menu_select(struct cpuidle_driver *drv, struct cpuidle_device *dev, /* * If the tick is already stopped, the cost of possible short idle * duration misprediction is much higher, because the CPU may be stuck - * in a shallow idle state for a long time as a result of it. In that - * case, say we might mispredict and use the known time till the closest - * timer event for the idle state selection. + * in a shallow idle state for a long time as a result of it. + * + * Add a 25% safety margin to the prediction to reduce the risk of + * selecting too shallow state, but clamp to next_timer to avoid + * selecting unnecessarily deep states. + * + * This helps on platforms with high C-state exit latencies (e.g., + * Intel server platforms 2022+ with ~150us) where using next_timer + * directly causes excessive wakeup latency when the actual idle + * duration is much shorter. */ if (tick_nohz_tick_stopped() && predicted_ns < TICK_NSEC) - predicted_ns = data->next_timer_ns; + predicted_ns = min(predicted_ns + (predicted_ns >> 2), + data->next_timer_ns); /* * Find the idle state with the lowest power while satisfying -- 2.52.0