From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from desiato.infradead.org (desiato.infradead.org [90.155.92.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BACC52D63E5 for ; Tue, 28 Jul 2026 14:42:34 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.92.199 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785249756; cv=none; b=bN1k61wbLuMCtrrYO/uzz4PC2gKA8jhqEJBmFB1+fuSQUDygYqwiiPc5+dzpk6MYJn+wTXZ4pUAEZJm1qM06j9PT3lu+XJsl2d3l4LhOtEj+rJYaWNeV8OhoS9fP1xzulv6kyV6W6q8jjE+KjBnaIjWLrzm6gitAylMTzlR00MM= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785249756; c=relaxed/simple; bh=K7eVsk4ojw3zmetpsO0Ar4wS6yAg3DGdbw8irWl+4qU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=aGyOK8CS8ql60+JN5vS/0sHYRGZvfjfUkP5Kl7OCA+0hEM+wx4xXVpUBvIdln5PdMLzWiNBBFKIoi5dHefkex291RUz4DXoRaRd50jeFNMlEUlizWdAzd8+aVxn7OUr3uPIg1R08laNoxMSTrQ6RxtVJT0kItQaEKn/Z2cYjJsE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=pass smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=JvAP1UiQ; arc=none smtp.client-ip=90.155.92.199 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="JvAP1UiQ" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=desiato.20200630; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=Fp7NCXSqrKdNsepu1PccXT8wBi0DM6o+vegoJP32DTQ=; b=JvAP1UiQZdtJuUW9I6AcNBeYeE ghc+gN1Y4yBFo3nXs7ph0murrOF59O6Qukww3z2RmT1DE0NENR++QHrPKb//lkLQMCncwJpf2nkzV md+gANvJ1/xrjuH4gRcCOZGys9qOtyPtwT8HAglcbc4mljvtWXP/oHedUMioyz69yT7o4OfOv44E/ rB1Jm/Tw5c36RS/8erFrC7CkJDdc2WF+JvGYcKOIBcehJY0sa36fm94YwT8lCFs2orswO/rWBJNf1 Kv3gc7cN5Gua8kEidTiCY1ptqrRAAlx/RZaRtqIq4TS/GHRx4EORIwNU+uNvouXcV4x9Usr9o0Pw9 to6+Lc6Q==; Received: from 77-249-17-252.cable.dynamic.v4.ziggo.nl ([77.249.17.252] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.99.2 #2 (Red Hat Linux)) id 1woj0j-0000000527X-3T13; Tue, 28 Jul 2026 14:42:26 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id EABE6300969; Tue, 28 Jul 2026 16:42:24 +0200 (CEST) Date: Tue, 28 Jul 2026 16:42:24 +0200 From: Peter Zijlstra To: Jing Wu Cc: 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 Message-ID: <20260728144224.GH651302@noisy.programming.kicks-ass.net> References: <20260728-bug-isolatecpu-cpufreq-v1-1-e95d34db8bcd@gmail.com> 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=us-ascii Content-Disposition: inline In-Reply-To: <20260728-bug-isolatecpu-cpufreq-v1-1-e95d34db8bcd@gmail.com> On Tue, Jul 28, 2026 at 07:27:54PM +0800, Jing Wu wrote: > An isolated CPU covered by nohz_full stops its periodic tick once it > has only one runnable task, since sched_can_stop_tick() only checks > scheduling-class fairness and has no notion of cpufreq reporting > needs. arch_scale_freq_tick() runs only from scheduler_tick(), so > cpu_samples for that CPU is never refreshed again. > > arch_freq_get_on_cpu() then permanently hits its staleness check and > falls back to cpufreq_quick_get(), which returns whatever policy->cur > was left at (typically the P-state floor). This happens even though > HWP hardware keeps running the CPU at full turbo autonomously, as > confirmed by turbostat and by directly reading APERF/MPERF. > > Reproduce on an isolated, nohz_full CPU with intel_pstate/HWP by > loading it and watching scaling_cur_freq stay pinned at the floor: > > taskset -c $CPU stress --cpu 1 & > for i in $(seq 10); do > cat /sys/devices/system/cpu/cpu$CPU/cpufreq/scaling_cur_freq > sleep 0.5 > done > turbostat --cpu $CPU --interval 1 --num_iterations 5 > > scaling_cur_freq stays at the floor for the whole run, while > turbostat's Bzy_MHz confirms the CPU is actually at full turbo. > > Refresh the stale sample with one on-demand arch_scale_freq_tick() > via IPI before falling back, but only when the target CPU is online > and not idle. APERF/MPERF both stop advancing during idle (C1+), so > a delta computed over an arbitrarily long stale window still yields > a correct busy-time frequency average. 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.