Re: [RFC PATCH 0/4] cpufreq/amd-pstate: Per-core EPP boost for recently-busy CPUs

[David Vernet]

On Tue, Jul 28, 2026 at 03:17:50PM +0100, Christian Loehle wrote:
> On 7/28/26 08:31, David Vernet wrote:

[...]

> > Testing methodology
> > ===================
> > 
> > All numbers are from a Steam Deck LCD (Van Gogh APU) running in active
> > mode at EPP=balance_performance, using the Civilization VI graphics
> > benchmark as a single-thread CPU-bound workload with a repeatable
> > built-in benchmark pass.
> > 
> > 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.
> > 
> > Results:
> > 
> > Default settings
> > ----------------
> > The busy core's median frequency sat at 2.43 GHz despite 98%
> > utilization, which is the frequency droop described above.
> 
> 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 = 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 = 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.

Attachment: signature.asc
Description: PGP signature