From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) (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 32AF843F091 for ; Wed, 29 Jul 2026 08:22:36 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.216.41 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785313361; cv=none; b=cuNa5sAAVInddWi0wQfcxq02/Dfx4MjeyPU98cKYM+QjiSRlh3thgxPWDH8FWXS2DNuvwMQKOxGHwKCYi6sbQqV9MQ8A7UYQclOJ+IjqacdMcGPrnjgIl4/FCOdZE3ek/EjBT0VoSyu7Jqtt5HqKtjQfm99KnxA16eB7DfzwnBs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785313361; c=relaxed/simple; bh=+y8g7fc9DUMndvps1fT5E0P/cY49eeVF/Qg6Wjl6Ux4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=E5plMj70Qm+HqooBvYZcKe7ZB7VNg7clJBUDp8ewUVXbbU/BNzzyesdBDEHIJ2FZiy5eKul6TRi2h87/ZPQV8jq4SQlf/nAzoXmzkihQulwJgRnguKLndEqyjv7dV/KEDrIheEJitqdX43XhtqRJrh2bhCbj686YTw0ulhFiCFs= 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=SL/71mGG; arc=none smtp.client-ip=209.85.216.41 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="SL/71mGG" Received: by mail-pj1-f41.google.com with SMTP id 98e67ed59e1d1-38e3617ba36so791270a91.3 for ; Wed, 29 Jul 2026 01:22:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1785313354; x=1785918154; 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:content-type; bh=+y8g7fc9DUMndvps1fT5E0P/cY49eeVF/Qg6Wjl6Ux4=; b=SL/71mGGjMuoQMFOMJ3R1oc7uzoir/Jpd0uasfMMsXxYDgmBA2Qg7NlSHNRvfTyZNT qcYASL5+JESZHqKS7HFlKziaWCW+JSe7vZQ5cvc3EkPswhQenry/tSdKekaip3LlsHxn D+fhpHul5eLPBkB+6pEdbLfs3uSo8n1c6V578OYF5O8WFdL225LvwCSqKGPYj4ntynv1 t8ozEPHcnmSH0+YL815obWDteidr3KSYpkULLfOXlLDz0OtFQ9LBWukV/PxgssZMSX4F cHx1d+XKS0df9csriPcKinICaa4OJiRLy2UE6ReNVxk1VUR8d5hdCSit16DfeQfyIlpI aFyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785313354; x=1785918154; 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:content-type; bh=+y8g7fc9DUMndvps1fT5E0P/cY49eeVF/Qg6Wjl6Ux4=; b=U3PCUycxCG1tdFFu9jipLxAPYDNYwoWoUCJ5ezYHu6pcxNhCs4LuuhjNAhyo6jqMPk R5xyiFsJw3YbITUxEktZpBvNd8DtVTvBAzhK6LFd1X6ocSnTIkMUhD2jyk8RplPPnk+K ZBwpZG9Vb63fY2y3R0xmtB4WvzcBzy81pQE9nhmQug68EM+NI2OCbaB9qZrFuFExIFOa v6Xd05PcnCYwPPhe7myfTmyyRPpSd7Sfj4P9Tf3F9yS4FbjkhHF9u8jTDIo6C+dGTPGP PCXFEp6zPP/6ax0bZi/7bA0X8qKIEeOaLlZD1D0g72G+Vh7cG3fTW8tHfn0Vwoc1IXHH zIQw== X-Forwarded-Encrypted: i=1; AHgh+Rq/qXKO8LBrGPueY64hqjM0w/y5csZ94ZO2eR3jW87yRp2gurMoUdXJ/B873y7U5dB8NScBYlRTwRQQNDM=@vger.kernel.org X-Gm-Message-State: AOJu0YyRbCvbYK9vzdmhAMoWoMsYo791TGgp/yk8kISVIMAvE/DIU/Tq qZgY+46HULvyldbFG7iLafEWc7ZeCd+9PHOaFnz4lZcXNA29+3snHFZ3 X-Gm-Gg: AR+sD11uPNuFZW+XNdTgEhIPO/NijTHd17pb47TSJIn1xIKScFH79X4CHXX0dOYf4Os HnlixWk4RxpK1DYKXhL1pVpjBFXOxe35BnN3kTEcjVBGc2m6A6WScnv67jTSBG0+ZG/ZLgD/xgB Yx6R8fhBhCkEaRo/BDArAZB0ggai81GPLD5ojyDntSQdXsNnz5YMgOzC0gFU95X0exa3fNOiqQR 1X8HsyZ3qyYz8Doo9al2XDM4d5WVnoPPYGf28CeUY7O6LkQIHjxoXaVLkHR5PTKX8mVtbRWnDAB pvXk9h03q2N50NqsWsrTUGVnV9eO14kYubOlvrt0XOOi/8/TratVQLIa8OqczRfqT5lV+fHfZTr +4zUMdu1AlB+kZxj/oKIOdXoQ+M99mr3rtlEZVrMU5F0XXHG7MqKgde10B89JPDthLXLBsbbTyU 1YxkGdMRvGwqBc+oiIwZx30IkEyl2sbRurCM0FgrRFtiSm0aVFTUXxBQ== X-Received: by 2002:a17:90b:388c:b0:381:bc4c:da5b with SMTP id 98e67ed59e1d1-38f6a376765mr5442073a91.18.1785313353771; Wed, 29 Jul 2026 01:22:33 -0700 (PDT) Received: from ubuntu.. ([23.254.208.9]) by smtp.gmail.com with ESMTPSA id 5a478bee46e88-31504d2ec2asm8564642eec.21.2026.07.29.01.22.28 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jul 2026 01:22:33 -0700 (PDT) From: Jing Wu To: Peter Zijlstra Cc: Jing Wu , Thomas Gleixner , Ingo Molnar , Borislav Petkov , Dave Hansen , x86@kernel.org, "H. Peter Anvin" , "Paul E. McKenney" , "Rafael J. Wysocki" , linux-kernel@vger.kernel.org, Qiliang Yuan , Jian Zhang Subject: Re: [PATCH] x86/aperfmperf: Refresh stale sample via IPI for busy NOHZ_FULL CPUs Date: Wed, 29 Jul 2026 16:22:24 +0800 Message-ID: <20260729082225.1675233-1-realwujing@gmail.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260728144224.GH651302@noisy.programming.kicks-ass.net> References: <20260728-bug-isolatecpu-cpufreq-v1-1-e95d34db8bcd@gmail.com> <20260728134434.GU751831@noisy.programming.kicks-ass.net> <20260728144224.GH651302@noisy.programming.kicks-ass.net> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit On Tue, Jul 28, 2026 at 04:42:24PM +0200, Peter Zijlstra wrote: > Aside from the fact that sending IPIs to NOHZ_FULL is just plain wrong, > this whole thing makes no sense. > > When the CPU is isolated, nothing should care about the ratio anyway. > Just set the thing to '1' (1024) when the CPU enters NOHZ_FULL mode and > ensure it isn't ever modified. Fair, understood. For context on why I went looking in the first place: stressing an isolated, nohz_full CPU shows both /proc/cpuinfo's "cpu MHz" and /sys/devices/system/cpu/cpuN/cpufreq/scaling_cur_freq stuck at the P-state floor (e.g. 800MHz) for as long as the CPU stays busy and isolated, while turbostat confirms the hardware is actually running at full turbo (e.g. 3.2GHz) the whole time. Both interfaces go through arch_freq_get_on_cpu(), so whatever affects one affects both. Getting the exact value would need an on-demand rdmsr on the target CPU - which is what turbostat itself does via /dev/cpu/N/msr's rdmsr_safe_regs_on_cpu(), i.e. the same smp_call_function_single() IPI, just triggered manually by a human running a diagnostic tool instead of sitting behind a commonly-polled sysfs file. I looked for a way around that: PCU mailbox telemetry can expose a per-core P-state on some Xeon uncores without touching the target CPU, and HFI publishes a shared table too, but that's a per-core performance/efficiency class, not an achieved clock, and PCU access is uncore/generation-specific, not a general mechanism. So as far as I can tell there's no way to get the exact value for an isolated CPU without an IPI of some form. Thanks, Jing Wu