From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f42.google.com (mail-wm1-f42.google.com [209.85.128.42]) (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 B401A289E17 for ; Mon, 26 Jan 2026 20:21:26 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.42 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769458888; cv=none; b=tgb30/XvgqRf9j23dgaJ0xlc3WB3FnKREWLMD4kFQIp7s/wyrR6uLfubwffgXD3M42MMvVb7E5v6Oy3NkkkidkYmQDTKFoZxRy/zuqyP6qHuBsOnYS/U4o+EUtoybLTYqKN7+4soS2qQeVuBV2NFerRkYXiG3Krsp9Fjc4JwJAs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1769458888; c=relaxed/simple; bh=xqu3YwpJVEVQZH29jJY+vRv4Bg+re1h9wvYTGv6IRJ8=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=lgrLnMtBtiYlI4vqPvXpX+7aLE/g9RI9vFar+lFWDl6v8oB8bbj/OzFmuOFg1FtihzBBavG3XOQzihFhdJYOM7BDiqO2QcdHQ6uOk0yK/G/hIbSE+cfrE6moQdv8iNOFLBueON6YMdO8QLUo2IUaPnCR/rEO2A3SbdoJE5v+cOk= 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=dAl4i0h7; arc=none smtp.client-ip=209.85.128.42 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="dAl4i0h7" Received: by mail-wm1-f42.google.com with SMTP id 5b1f17b1804b1-47fedb7c68dso49851545e9.2 for ; Mon, 26 Jan 2026 12:21:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1769458885; x=1770063685; 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=UhqRfC+ZkjKLBE27+UTSNmoxUrR+mo//ucpkrQIn4x4=; b=dAl4i0h7boIgW0uIEEKTxNpC0P9r4PcScZKTusrs2i6LmPohifk86m7DLXmmV3DUlY 7WuuH2EaFuwqaUYK0idLZ2tpZmWtmLIL6j8dt65Ia6w9gMmt1swT842oAi4vs9Kx0rT/ 1klJvhSoP8KN5D8FuRDRfoB4I8hI2lNOGHMygFbjomtGPza4EmI55d/rGKV5QXSEBx8B iq9QqF1qbmfL/QE2F1cgplKZuwDy13Nd/y5baysA594U2zxxrK7zRReAD+ULq5nAPEc0 7yfFdo2wCqEAbCYvmjhJ5ym/yrw/3JMpjV1+ny7MtyHN+FgJaQfJOJfJfeOf01hDOc1M Gb1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1769458885; x=1770063685; 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=UhqRfC+ZkjKLBE27+UTSNmoxUrR+mo//ucpkrQIn4x4=; b=Ddg5Z0+bO/Ri1e5vGMudd+wBQqoub+99NMEjJ1p4ya1Rw51a4pMq+T1asPfTycPyrz 9GO+7L7xRAX3SLipEM2UGaGDWdYTiZ1ElohQ7iuiGOr9ITv0ClMit4K96N+ha24/uJxI PsTHJwp3igpbi2TaGYnX2qZr17h7aNJpbsPetDt6mAYoyo7gh9HLQkaFGZtdbUR7dcpM 0+yGbX9iAri8RDN22bxIquYd4RhaEHh/Gpjtq8iwoFYQXlzpXE5JA1FEQYe0x9AQuN9V mf0Trx9dHXrYieKgSaj6SR+In7oCkrdixybPORd/G4RHnWfn4/OFXpXs4cVElcewmd1w 2+9Q== X-Forwarded-Encrypted: i=1; AJvYcCXSJkeuXpKzMa+wA/JnEcorpQFM/u9/3azJD0y66PyVjGH1WXmnOTBSO2U2aov577FwbM0ABz84BXMG510=@vger.kernel.org X-Gm-Message-State: AOJu0YxZ/LQCFBkuS3Ajvn5SqYs6tFzhs7orXKu5XKJsrj9ZVElJSEd2 ANODqxV+TFwYj9YcPeK2PlFsUZU3W6gq217A4dMfb4J0H+3IFAphOFHy X-Gm-Gg: AZuq6aKfaxQkcHmCuo3O0pmV6X77OFFvLzoCbaXEiCUSKbAscH5Qv2nfvLoe9CPcNi2 ak0mX6VCcI15Jx8asAVTvnwa62/7f8EdJuLNH+EEPrDQyyJzZfDkCosgCgRHdE1O+8X+H64VKRK S2Ya+3ymL9phfUSyVOZlVWCtzrAK4zlB+9afb3VdpuYmKOR1pHOerfSbyxJSJQ+kBEwGrjIKrtR VEtSz+YyyGaMXKLgkVBpBfUpfFJqCxXN4rzq1Qw0xC8Cd2tGx1rseXOnmrufMkwCvoPH+ov5UYh Zvd0RRRBOjrpnSf5Dn5jfIS5lRtRhpc/lbFQP8egDoG+89JFkOGSiQZUGx9SXX5xcf8pr7qcw9C H8RXZQ2AfY2i9P3WfLWQ7+EgckmriZBEdJ6e6+Tedgr/o2aKp0rpzIYcn+jRGuQ2ktPK00VJL2f 8wlJ2lPpEsq81OIAwFZiFVU24wMtqt/TVAFXO9oA== X-Received: by 2002:a05:600c:34ca:b0:480:4a4f:c366 with SMTP id 5b1f17b1804b1-4805cf5ebdcmr95592855e9.20.1769458884833; Mon, 26 Jan 2026 12:21:24 -0800 (PST) Received: from ionutnechita-arz2022.local ([2a02:2f0e:c30b:500:c472:222f:bc60:d893]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-48066bee24dsm10554565e9.5.2026.01.26.12.21.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 26 Jan 2026 12:21:24 -0800 (PST) From: "Ionut Nechita (Sunlight Linux)" To: christian.loehle@arm.com Cc: daniel.lezcano@linaro.org, ionut_n2001@yahoo.com, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, rafael@kernel.org, sunlightlinux@gmail.com, yumpusamongus@gmail.com Subject: Re: [PATCH v2 0/1] cpuidle: menu: Fix high wakeup latency on modern platforms Date: Mon, 26 Jan 2026 22:19:44 +0200 Message-ID: <20260126201943.11505-2-sunlightlinux@gmail.com> X-Mailer: git-send-email 2.52.0 In-Reply-To: <54478318-cbee-46f2-9ff1-9c0ae15a89ab@arm.com> References: <20260122080937.22347-2-sunlightlinux@gmail.com> <54478318-cbee-46f2-9ff1-9c0ae15a89ab@arm.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 On Thu, Jan 22 2026 at 08:49, Christian Loehle wrote: > It was more of a question than a suggestion outright... And I still have > more of them, quoting v1: Thank you for the detailed feedback. Let me provide more context about the workload and the platforms where I observed this issue. > You also measured 150us wakeup latency, does this match the reported exit > latency for your platform (roughly)? > What do the platform states look like for you? Yes, the measured latency matches the reported exit latencies. Here are the platforms I've tested: 1. Intel Xeon Gold 6443N (Sapphire Rapids): - C6 state: 190us latency, 600us residency target - C1E state: 2us latency, 4us residency target - Driver: intel_idle 2. AMD Ryzen 9 5900HS (laptop): - C3 state: 350us latency, 700us residency target - C2 state: 18us latency, 36us residency target - Driver: acpi_idle The problem manifests primarily on the Sapphire Rapids platform where C6 has 190us exit latency. > Also regarding NOHZ_FULL, does that make a difference for your workload? Yes, absolutely. The workload context is: - PREEMPT_RT kernel (realtime) - Isolated cores (isolcpus=) - NOHZ_FULL enabled on isolated cores - Inter-core communication latency testing with qperf - kthreads and IRQ affinity set to non-isolated cores The scenario: Core A (isolated, NOHZ_FULL) sends a message to Core B (also isolated, NOHZ_FULL, currently idle). Core B enters C6 during idle, then when the message arrives, the 190us exit latency dominates the response time. This is unacceptable for realtime workloads. > Frankly, if there's relatively strict latency requirements on the system > you need to let cpuidle know via pm qos or dma_latency.... I considered PM QoS and /dev/cpu_dma_latency, but they have limitations for this use case: 1. Global PM QoS affects all cores, not just the isolated ones 2. Per-task PM QoS requires application modifications 3. /dev/cpu_dma_latency is system-wide, not per-core For isolated cores with NOHZ_FULL in a realtime environment, we want the governor to make smarter decisions based on actual predicted idle time rather than relying on next_timer_ns which can be arbitrarily large on tickless cores. > A trace or cpuidle sysfs dump pre and post workload would really help to > understand the situation. I will collect and provide: - ftrace cpuidle event traces - Complete sysfs cpuidle dumps pre/post workload - C-state residency and usage statistics - Detailed qperf latency measurements Regarding the safety margin question from v1: you're right that I need to clarify the logic. The goal is to clamp the upper bound to avoid unnecessarily deep states when prediction suggests short idle, while still respecting the prediction for target residency selection. I'll send a follow-up with the detailed trace data and measurements. Thanks for your patience and valuable feedback, Ionut