On Tue, Jul 28, 2026 at 04:02:34PM -0500, Mario Limonciello wrote:

Hi Mario,

Thanks for reviewing this!

> On 7/28/26 02:31, David Vernet wrote:
> > In active (EPP) mode the platform autonomously picks the operating point
> > between min_perf and max_perf, biased by the EPP hint, and the kernel
> > only rewrites the CPPC request on policy/limit changes. A workload
> > dominated by one mostly-busy thread that takes frequent short sleeps
> > (e.g. a game render thread blocking on a futex waiting for the GPU or a
> > worker thread on every frame) can defeat the platform's utilization
> > tracking. Each sleep decays the hardware's performance signal, so
> > post-wakeup bursts start at a low operating point and the frame-time
> > tail inflates even though the CPU is ~100% busy during the frame itself.
> > 
> > This is a common problem in gaming workloads, and is not easy to solve
> > at the cpufreq layer. We have to toe the line between running at a high
> > voltage unnecessarily and draining battery (and potentially contending
> > with e.g. the GPU for power draw), and lowering frequency on the core
> > that's running the game's main and/or render threads (thus materially
> > increasing frame latency and causing a tail increase in stale frames).
> 
> I have to question - is this really a good use for active mode?   You're
> basically fighting with the hardware and trying to game the behavior.
> 
> I wonder if for gaming it would be better to enact guided mode and then let
> userspace limit the range that it can act within.

Yeah I think this is a reasonable callout. This is being discussed in
some of the other threads, so I'll defer to those so we can keep the
discussions in one place.

[...]

> > The mechanism works as follows: When the epp_boost module parameter is
> > enabled, an update-util hook samples each core's C0 residency (delta
> > MPERF over delta TSC) at most once every 10 ms. If a sample shows the
> > core at least 50% busy, the EPP field of its MSR_AMD_CPPC_REQ is set to
> > performance (0) and held there until 300 ms pass without another busy
> > sample. The hook then writes back the request that policy management
> > last stored in cppc_req_cached. Both writes happen only on the busy and
> > idle edges, so the CPPC_REQ write rate matches that of a global
> > EPP=performance setting. min, max and desired perf are never touched.
> > This mirrors intel_pstate's hwp_boost, except that hwp_boost triggers on
> > SCHED_CPUFREQ_IOWAIT, which the waits at issue here (futex waits and
> > amdgpu fence waits) do not set, so a residency trigger is used instead.
> 
> I understand using epp_boost in the context of a module parameter to easily
> activate this behavior, but I don't think that's the right way that it
> should be triggered because it's going to end up effective for the entire
> boot even when you're not running games that you want to use this.
> 
> I'd think a sysfs knob would be better to activate it if it's going to be
> dynamic

Ack that makes sense, I'll use a sysfs knob in the next version.

> But also - dynamic_epp isn't the default behavior.  What if you
> only activate this when dynamic_epp is set?  IE when using dynamic EPP you
> use platform power profile, power charger, and this running algorithm.

Sure, that might be an option. I'm planning to rebase onto Prateek's
patch set this weekend to test this out, so let's see how that looks and
then we can evaluate further.

[...]

> > +static void amd_pstate_epp_boost_update_util(struct update_util_data *data,
> > +					     u64 time, unsigned int flags)
> > +{
> > +	struct amd_cpudata *cpudata = container_of(data, struct amd_cpudata,
> > +						   epp_boost_update_util);
> > +	union perf_cached perf;
> > +	bool first_sample;
> > +	u64 busy_pct;
> > +	bool active;
> > +
> > +	if (smp_processor_id() != cpudata->cpu)
> > +		return;
> > +
> > +	first_sample = !cpudata->epp_boost_last_sample;
> > +	if (!first_sample &&
> > +	    time - cpudata->epp_boost_last_sample < AMD_PSTATE_EPP_BOOST_SAMPLE_NS)
> > +		return;
> > +	cpudata->epp_boost_last_sample = time;
> > +
> > +	/*
> > +	 * Counters can reset across suspend or hotplug (so their values would
> > +	 * be garbage), so just recalculate baselines.
> > +	 */
> 
> This comment confused me.  I at first thought you weren't doing it, but you
> are.  Basically on resume you treat it as a fresh startup.  I would just
> drop this comment.

Yep, in hindsight I agree this is confusing. I'll drop it from the next
version.

Thanks,
David