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 053B630E846 for ; Fri, 5 Dec 2025 16:11:01 +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=1764951071; cv=none; b=FwAPm3FxGWrJVkpImM/k7G3J/IIzTPuQTD3SH9wJLRhzq817BsFFA/QJKLsS9XYFTUMarTkA4tsTE4TjIwBvmWTi3rpl98hD7zCXmyBgWCK7wI3M3OuO/bWC4+CYFIDaUxXzDGlHkJauh8XLvZnizeOrAxlPgOErWcwdcWh7hos= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1764951071; c=relaxed/simple; bh=SxNzUFLwrfNObxx3G3bd2cofSySnVM0HIl0N9Q+ZeAk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=LRy9J68VMTwWVQq9FA305U9SmPxdVlY5OLCrcXFIbdETfkEiQ/q1sVmJGKUoo/l8ExdEvG6usv7BdXZwmDQnTU2/S332aQkoir2dp6a9kCI8vGIkkioOs0n9EbIBiEnkSJxsgsuYaJJK/mdC+iH+xf0+dAM94Fc3hx3eDDnfHAE= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=ftbMlTM+; 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=none 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="ftbMlTM+" 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=ZJXATwxUmBwV/LTemFPNucE1/Gq7IS6baGIhD6UAsWY=; b=ftbMlTM+vtjg27AD5idJW+saau sSLNWhz7l0Ja8LcUrv3l3NVOFcvz5OnJgJynp8EvEem2Ucpkr/3p0gf2a5Ct+M4P/Qb0faxmCp8tV hiHtlri0ddQrVjiyUA86vhd7XOwLMAE5pX7B8o1hL9/IvTIA7E11FxV4t7oG3am6YjEvOGHXVMw8n pfXb5jR5khqq6EHBPouf2okrW2k50GzX99quH+aRqPk7Vn3VcEF4yApkL7PFAawDIgqJp+adv+XYw e7YZl+Z1CkRf4z961Xv1Pi9Aaaln2DRxnc4Yc7mE1BRJKEneMtAqm/crr2P6NoP8SCM8MMSXxONkg SwZbbjlg==; Received: from 2001-1c00-8d85-5700-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl ([2001:1c00:8d85:5700:266e:96ff:fe07:7dcc] helo=noisy.programming.kicks-ass.net) by desiato.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1vRXWx-00000006Jeu-1ul3; Fri, 05 Dec 2025 15:15:35 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 8FA73303076; Fri, 05 Dec 2025 17:10:52 +0100 (CET) Date: Fri, 5 Dec 2025 17:10:52 +0100 From: Peter Zijlstra To: Andi Kleen Cc: linux-kernel@vger.kernel.org, x86@kernel.org, ggherdovich@suse.cz, rafael.j.wysocki@intel.com Subject: Re: [PATCH] x86/aperfmperf: Don't disable scheduler APERF/MPERF on bad samples Message-ID: <20251205161052.GH2528459@noisy.programming.kicks-ass.net> References: <20251204180914.1855553-1-ak@linux.intel.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: <20251204180914.1855553-1-ak@linux.intel.com> On Thu, Dec 04, 2025 at 10:09:14AM -0800, Andi Kleen wrote: > The APERF and MPERF MSRs get read together and the ratio > between the two is used to scale the scheduler capacity with frequency. > > Since e2b0d619b400 when there is ever an over/underflow of > the APERF/MPERF computation the sampling gets completely > disabled, under the assumption that there is a problem with > the hardware. > > However this can happen without any malfunction when there is > a long enough interruption between the two MSR reads, for > example due to an unlucky NMI or SMI or other system event > causing delays. We saw it when a delay resulted in > Acnt_Delta << Mcnt_Delta (about ~4k for acnt_delta and > 2M for MCnt_Delta) > > In this case the ratio computation underflows, which is detected, > but then APERF/MPERF usage gets incorrectly disabled forever. > > Remove the code to completely disable APERF/MPERF on > a bad sample. Instead when any over/underflow happens > return the fallback full capacity. So what systems are actually showing this bad behaviour and what are we doing to cure the problem rather than fight the symptom? Also, a system where this is systematically buggered would really be better off disabling it, no?