From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ot1-f53.google.com (mail-ot1-f53.google.com [209.85.210.53]) (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 8141622E3F0 for ; Thu, 30 Jul 2026 05:57:49 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.210.53 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785391072; cv=none; b=Dq31IOgLa/BRm+hPbDRn2eWRmBLoEWTpJDOAkxfcOoqmYMFrHCLh3hgsXH4G8PaZ3icaSWlYS9AX9rwH6ibHat2eu659aecEsqg9s2HXz8+Chr2gNpen0Eq+0kBQJ3OI8+GlqkPSJVJnmFx7YR0L9bw96bpW0OhCUKplVldYmjU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1785391072; c=relaxed/simple; bh=elrJJODL1Vl6dYW/ghsCTBe3TiiL2VuRJbi5aBpjw0E=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=EwkmIsMC/FPkupNjtHFR1OtXkl2e35ID1Lgd5ar6pNQr+yZRvKofFZh01xVCb8+MlQL5eMbw/JLdaYlkrsHhEO9oIikYcSlu/VEgwwgVhrk0aTIWbMln8tB6EzYtYyuI7nRJEsZL/sKdDM7DfOrOuV/bThpH0GfDHb1d+jnL94U= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=manifault.com; spf=pass smtp.mailfrom=manifault.com; dkim=pass (2048-bit key) header.d=manifault-com.20251104.gappssmtp.com header.i=@manifault-com.20251104.gappssmtp.com header.b=FkwD79h8; arc=none smtp.client-ip=209.85.210.53 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=manifault.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=manifault.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=manifault-com.20251104.gappssmtp.com header.i=@manifault-com.20251104.gappssmtp.com header.b="FkwD79h8" Received: by mail-ot1-f53.google.com with SMTP id 46e09a7af769-7e9f69ee6f4so1682029a34.2 for ; Wed, 29 Jul 2026 22:57:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=manifault-com.20251104.gappssmtp.com; s=20251104; t=1785391068; x=1785995868; darn=vger.kernel.org; h=user-agent:in-reply-to:content-disposition:content-type :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to:content-type; bh=G1YBtjGWPIAJs8RYckw93SW7NOctckdT45mokOADGow=; b=FkwD79h8TyjKfaenSqW8aOzBZ2cVc2dmk+kp5Iil6++ndY5Ykx5dIzsvE1qZZ3jbVv gesBiEl0wfdB9H4F/Z5gCC2ZW9f26/63DPEmSKt6t44LsPUJiDXHeqvYeeBI5zx2xxWt hdVxrhKv8ry9XMhKyOgLCc7cYUnGqI9bQu+cvGsTV4g4mbrGUAKk8FQ4Vx8hxilBBDGY DMGlr4YR6w8e1T6Ywlw00rK8eNHIhQkkI/Obat9m4vZtF9LtVISqZj7rsdMDslepIozO dTKOZFiGe+43piJpyLcakXqEsz8gfUwGmmHOqghzmomMXl7gDeFyIZ4+tHvilOasRLQM vQEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785391068; x=1785995868; h=user-agent:in-reply-to:content-disposition:content-type :mime-version:references:message-id:subject:cc:to:from:date:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to :content-type; bh=G1YBtjGWPIAJs8RYckw93SW7NOctckdT45mokOADGow=; b=qURXq8ea9Cu9zfaBLEhU8wsdPsAMOFp/QpLh2EujEdqH4Mq0M9Sk3JCYvYH9OdR5UT 9foDLmD4RMyyH+RwjyrpieL5565lZJHX2WZVqiYDbxXtI2GymOe2PWNv+YTIV5bQ1O4t jkCr4T66kfEGGv2ofcRbHpanXvnKWk3lpCK0+hb0ZlOy+ZtjkUsJPf7l0Xx+unwszJLN BOBE1RLwhtVdZERfeUnpNwvUrIeKPNgbdocQw0+xTFUl+dNjbMX3lqQvi7eTTmOsamS0 1MYBDd9uIiSRm0DZwHRZhHRwK5flI9UYGt89hK+pYAMz8TTuEJcn5NNl5LgiFYPsxod4 jiMw== X-Forwarded-Encrypted: i=1; AHgh+RpHh3OLQ9TFxmy+VNXGZrRy9wq5psEyhhkhsMh7cVhyAGE16Vl9ozz4M4Nu1xUgVVOZehANKeJF6ho+evs=@vger.kernel.org X-Gm-Message-State: AOJu0YxXaM8tSVdHJDUjI44Wrh1T4MuZeXkflYiv/auHrTFeKkkDwo+R zk9AE3uMAQffWQhEBYXOHbGxKStAnkQjyoR/86bRraLJeaXbiGst2f6C0f8AhNOg1cfY X-Gm-Gg: AR+sD10uPCX6Hkv/6LtMfndKqJeV3aKw3+BSGZ2G3UjnqTdFf7CbywXhGI6gPzyVkNt 0sjA1l/lRvxQonoJG3WaQv5krMX1uUjD/OOKMrZrdXKIySsy23K/Q9F+JnqhUh1CIw+vnx9qNmT 2G3GRDSrJR9gePmJFG6Mo9cgmVjAlYRCp7I708AJOK4n2daVlpIhglyj+t48k/FU4CqksW67aU1 ftXk/Dp6bCYBx+5vLdrLBiGcFpZxS1ucP1ez0qYSnSozv9ZHuyyKSOa3X8Fy8KNv/lyAVfMHrOA UEeLKDZ+MGnWxC1zhOe0MqTzo4ngOx6skIVirEfjEfcW4Dwz6WvZSY/db0QbaYl1W+TsVsp1+8e /sFRb/NG1V56cwEdAuWkOSj31EeEUNrEc+MELUHB0gHGz9iYsaxSqBP2QZqFpuyii78KuQszDW6 ukt5qe21Gh9aTPoZNsATCCjK53ES8Bb+2l12wMt2GXNSgRv7sBa1viytUArxiJfS2wbkNwzizAZ +LqvYlvTsIfh2wc7TRmU7td5d+U70Sb0VY= X-Received: by 2002:a05:6830:310b:b0:7e4:163:49cc with SMTP id 46e09a7af769-7f02bed52d5mr669619a34.7.1785391067870; Wed, 29 Jul 2026 22:57:47 -0700 (PDT) Received: from localhost (c-76-141-129-107.hsd1.il.comcast.net. [76.141.129.107]) by smtp.gmail.com with ESMTPSA id 46e09a7af769-7f00d591de0sm3955057a34.1.2026.07.29.22.57.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Jul 2026 22:57:47 -0700 (PDT) Date: Thu, 30 Jul 2026 00:57:45 -0500 From: David Vernet To: Christian Loehle Cc: "Rafael J. Wysocki" , Huang Rui , Mario Limonciello , Perry Yuan , K Prateek Nayak , linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, =?utf-8?B?QW5kcsOp?= Almeida , Changwoo Min Subject: Re: [RFC PATCH 0/4] cpufreq/amd-pstate: Per-core EPP boost for recently-busy CPUs Message-ID: References: <20260728073150.54964-1-void@manifault.com> <700ebebe-f4ab-4329-ad43-716d74d6621c@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="wtdukudjwzownic4" Content-Disposition: inline In-Reply-To: <700ebebe-f4ab-4329-ad43-716d74d6621c@arm.com> User-Agent: NeoMutt/20260105 --wtdukudjwzownic4 Content-Type: text/plain; protected-headers=v1; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Subject: Re: [RFC PATCH 0/4] cpufreq/amd-pstate: Per-core EPP boost for recently-busy CPUs MIME-Version: 1.0 On Tue, Jul 28, 2026 at 03:17:50PM +0100, Christian Loehle wrote: > On 7/28/26 08:31, David Vernet wrote: [...] > > Testing methodology > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > >=20 > > All numbers are from a Steam Deck LCD (Van Gogh APU) running in active > > mode at EPP=3Dbalance_performance, using the Civilization VI graphics > > benchmark as a single-thread CPU-bound workload with a repeatable > > built-in benchmark pass. > >=20 > > Comparisons were run as interleaved A/B tests with 6 iterations per > > configuration. For each run I collected per-frame frame times and the > > busy core's frequency, and derived average fps, 1%-low fps and the p99 > > and p999 frame-time percentiles. Deltas were evaluated with Welch's > > t-test, and I report the p-values alongside the deltas below. > >=20 > > Results: > >=20 > > Default settings > > ---------------- > > The busy core's median frequency sat at 2.43 GHz despite 98% > > utilization, which is the frequency droop described above. >=20 > Two things to confirm for my understanding: > -Median frequency is the 50th percentile when weighing the OPPs by > residency, right? Yes, effectively. It's the median of 500 samples of scaling_cur_freq taken at 50 ms intervals. > - You're also using busy_pct =3D delta_MPERF * 100 / delta_TSC as > utilization, right? (Not util_avg or anything like that) The 98% I mentioned in the cover letter is the render thread's on-CPU share of wall clock during the benchmark window. The trigger in patch 3 is busy_pct =3D delta_MPERF * 100 / delta_TSC. > Your observation looks like a firmware or SMU issue. > Can we confirm the (short) sleeps reset the demand-estimation, i.e. > by tracing cpu_idle/sched_switch and sample APERF/MPERF alongside it? Good idea. I ran this experiment and I think you're correct that it's a firmware or SMU issue. I did three 60s captures of sched_switch + power:cpu_idle via trace-cmd during the Civ6 graphics benchmark with a pinned sampler reading APERF/MPERF on all 8 CPUs at 1 ms alongside, and it showed that frequency drops from 3.5 GHz to a ~2.4 GHz plateau whenever the render task blocks for more than .2 ms. This drop then seems to persist for at least 8ms after the task wakes up (sometimes persisting for several seconds). I also don't think C state matters here, as this happens even if I restrict cpuidle to POLL and C1 only. This is the post-wake effective busy clock, controlled for how long the render task was blocked: idle time pre 0-2ms 2-4ms 4-6ms 6-8ms <0.2ms 3.50 3.50 3.50 3.50 3.50 0.2-0.5ms 3.49 2.43 2.42 2.43 2.43 2-5ms 2.43 2.43 2.43 2.43 2.42 >5ms 3.50 2.43 2.43 2.43 2.42 > Also rt-app might be helpful to get a feel of how this behaves (and > create a similar pathological case like the single-threaded game). Yeah that's a good idea. I can try that this weekend. --wtdukudjwzownic4 Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQRBxU1So5MTLwphjdFZ5LhpZcTzZAUCamrn2QAKCRBZ5LhpZcTz ZP+uAP97ci2qOjVPXysUzKo09+70aSVYX0X6eRdsu5udrileWQD+PXhWoCsNsVwj U8CqTR0e6AOp/ia7yjI9bmWkoRcongo= =ZVUo -----END PGP SIGNATURE----- --wtdukudjwzownic4--