From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wr1-f47.google.com (mail-wr1-f47.google.com [209.85.221.47]) (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 4DD10314B62 for ; Thu, 22 Jan 2026 08:10:10 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.221.47 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769069413; cv=none; b=tuDsdd/VPEwyqieNl1r3MisC4Ni5f99Kr5WOtzEy8eZDV4NNrKSklWQo2pu2mxAjWQhHiGGZOyqtsveLvd91EgCUbA4qiuZ6br5q/o0U9pFkGyoA8KpkMCVar1lKPJzIONLgi9Da1mGgBTvlYrwcTgM21452xsy4upi30aYcLt8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769069413; c=relaxed/simple; bh=ly+ObxefnjO7zqPiNFOgC5SzOHX1YJWNyvBq6FWUlKo=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:Content-Type; b=uh3io4Ysyl9ApnzjQAx9iX3OKG9IFykBu3zBTJdI8N68Z/lZTAJIG7g1WeNGvj0lmlBeMTWU7QdnjIqNdOUPdKNJ2cW53NxoHdLa9KazaXlz/CwN46skEBwuTZCiR5NkB8rHYXcZVOHs1IDGOos3nMSR7SaHXwQFFlYSOZF6yLY= 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=LJwhJBcS; arc=none smtp.client-ip=209.85.221.47 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="LJwhJBcS" Received: by mail-wr1-f47.google.com with SMTP id ffacd0b85a97d-42fbbc3df8fso427286f8f.2 for ; Thu, 22 Jan 2026 00:10:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769069408; x=1769674208; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=QNSsO4GTvrQKxmXyShjL87zNttG4r0OUhsCw6jrsiXI=; b=LJwhJBcSvNmD1HegQdNk+CfodMZAH8Wgud6HTB8d+enZO69IME4IwZ+KsdPgkCcVhj y5Kxjpc0WyDIhxxc5jz5bCnWY8KVU00QY2II+Z+k5LLgpcuyLPGPIPJTJf79b4ttimtj sAuxfv4D5HV5q9S35byZr8FO07d32HabGov5bVCschTk0hyRg1ZaWfj8akfpl4t2gm3u eTRFXjc7QLNLaL/TDkZJwLnwPcfJVdjTET0TFPx9+O4AyAlANBBejle1DEEAAeIpTi6+ BO0QyeCiggjVSlAyfMP/h0ekTWiQTdf9bM6IF2TEk0B1z6tEruExVdSnJMLmwslOw8wF 00wQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769069408; x=1769674208; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=QNSsO4GTvrQKxmXyShjL87zNttG4r0OUhsCw6jrsiXI=; b=v9wpHqZOY8FKp0/Sa89Ojo5vQh6AZDE94GwCEKXARyUGALRIPPFDF6BIyQP2eBQ0xC WuH4iVPO+R84sRwCRU7a2oMT+nZeSp9L7SqmxGZN32kfNVdw/QqWGapu1Tmxu0njCrJ/ rWVbqDqbpb4p9wl79l6N+D6esETbkuJABYrqOIb+4lYavPM4U6eU9fx8rJGkM1JtzYTU w8kcZWAcNNFfxHf50Fz/0MK6SvEid08tx86lapAuxRE/1/9Qyt+BbNiL6s2kRsaw1OnS zzgCuGGevL+dL597D9++2PhPr3qGO6HddBXKBGE077S6MSFhkW79Rij0USD7MHMWDvTb y3zQ== X-Forwarded-Encrypted: i=1; AJvYcCVq4O2RQJou7E8VekXWmgvmfT5uNDi7Vtaq7nGYfgAe1f5j8eLZ5YF2wXqXbammR4XuKvgMWEFzUDoM2bY=@vger.kernel.org X-Gm-Message-State: AOJu0Yx55MXPsS+jgLoCKSf1J9A0fg2m81w3WkljWdnM9qiPXqRETvTZ CMVzJDR7sCn+yVIEPlxq6oZIceJPvi+XfdCVE/ukLijsMnWVaoTOloiz X-Gm-Gg: AZuq6aJL0M2xYQMwQ1cg7b93X+oJ9v9OWoO21Q87fDkXUUH56raI6cIZqepTc89XcNG 7iXv6cOtXDFiwyPxSYjTHWzIyw6vvq5vEsrMsmyHUDeMFRzRd2crgfA0ZNdxkBZuxJCPdS9JD7W Go22WUmUh2yHLSChjdXYtPZQ2OJ7zyHeSZMmu3Cyto5V8iwVjD1c600Lfmz+XufBvAUvwihzdbS IU/M1LSNewHdAHUD3/3oF4DdCnU9wjw2QsfEnb2aPZ0zz0hcZZQKfTLxM0OGUoYJZPXM5YccIaI o1k/s00y4R6DROLh82yO8Bl+Ii8uBV4WnwWqjelKk6CeXoxiP18ULMpzIlmuQUFcThdRNkoFHe3 maHudBUf4kh/g2QN3l0MycZQwTnmlBtZDnhhNVfZrCbN0ZSXWrrJPwX++/wce/2Swjk9cqlhCfQ j6GMBiK0ex0bSx7ZwK9xN08UtB8rYrzAlJrBT6tXA= X-Received: by 2002:adf:e3ca:0:b0:435:9522:2bc9 with SMTP id ffacd0b85a97d-43595222c80mr9996237f8f.5.1769069408176; Thu, 22 Jan 2026 00:10:08 -0800 (PST) Received: from ionutnechita-arz2022.local ([2a02:2f0e:c606:9800:ea1b:9133:ab8e:bdea]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-4356997ed8bsm43766261f8f.36.2026.01.22.00.10.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 22 Jan 2026 00:10:02 -0800 (PST) From: "Ionut Nechita (Sunlight Linux)" To: rafael@kernel.org Cc: daniel.lezcano@linaro.org, christian.loehle@arm.com, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, yumpusamongus@gmail.com, Ionut Nechita Subject: [PATCH v2 0/1] cpuidle: menu: Fix high wakeup latency on modern platforms Date: Thu, 22 Jan 2026 10:09:37 +0200 Message-ID: <20260122080937.22347-2-sunlightlinux@gmail.com> X-Mailer: git-send-email 2.52.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Ionut Nechita Hi, This v2 patch addresses high wakeup latency in the menu cpuidle governor on modern platforms with high C-state exit latencies. Changes in v2: ============== Based on Christian Loehle's feedback, I've simplified the approach to use min(predicted_ns, data->next_timer_ns) instead of the 25% safety margin from v1. The simpler approach is cleaner and achieves the same goal: preventing the governor from selecting excessively deep C-states when the prediction suggests a short idle period but next_timer_ns is large (e.g., 10ms). I will test both approaches (simple min vs 25% margin) and provide detailed comparison data including: - C-state residency tables - Usage statistics - Idle miss counts (above/below) - Actual latency measurements Thank you Christian for the valuable feedback and for pointing out that the simpler approach may be sufficient. Background: =========== On Intel server platforms from 2022 onwards (Sapphire Rapids, Granite Rapids), we observe excessive wakeup latencies (~150us) in network- sensitive workloads when using the menu governor with NOHZ_FULL enabled. The issue stems from the governor using next_timer_ns directly when the tick is already stopped and predicted_ns < TICK_NSEC. This causes selection of very deep package C-states (PC6) even when the prediction suggests a much shorter idle duration. On platforms with high C-state exit latencies (Intel SPR: 190us for C6, or systems with large C-state gaps like C2 36us → C3 700us with 350us exit latency), this results in significant wakeup penalties. Testing: ======== Initial testing on Sapphire Rapids shows 5x latency reduction (151us → ~30us). I will provide comprehensive test results comparing baseline, simple min(), and the 25% margin approach. Ionut Nechita (1): cpuidle: menu: Use min() to prevent deep C-states when tick is stopped drivers/cpuidle/governors/menu.c | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) -- 2.52.0