On Tue, Jul 28, 2026 at 02:43:46PM -0500, Mario Limonciello wrote:

Hi Mario,

[...]

> > > This series instead adds an opt-in, per-core EPP boost. 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, at which point the hook
> > > restores 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. The mechanism is
> > > only available in active mode on MSR (X86_FEATURE_CPPC) systems, since
> > > the hook does local MSR accesses from scheduler context which the
> > > shared memory interface cannot do. It composes with dynamic_epp, which
> > > selects the policy EPP from the platform profile and power source.
> > > epp_boost temporarily overrides whatever policy EPP is installed and
> > > restores it when the core goes idle.
> 
> Have you seen the series from Prateek that reworks how dynamic EPP works
> [1]?  It becomes an energy_performance_preference that userspace can opt
> into.
> 
> I did have aspirations to hook into more changes than just platform profile
> and power source eventually, so it sounds like we're at least thinking in
> the same area.
> 
> [1] https://lore.kernel.org/linux-pm/20260727072056.1248-1-kprateek.nayak@amd.com/
> 
> Can you rework your series on top of that and see how the mechanics work
> out?

I hadn't seen it before posting this, thanks for the pointer. Agreed
that we're thinking in the same area. The way I see the two fitting
together is that his rework decides the policy EPP from system-level
inputs, while this series temporarily overrides the EPP of individual
busy cores and then restores whatever policy management installed. So my
expectation is that they compose rather than compete, but I'll rebase
and test with his changes and report back.

[...]

> > > On the thresholds themselves, the sample period, busy threshold and
> > > decay window are hardcoded rather than exposed as tunables. I'm not sure
> > > if this is appropriate or not, but it seemed like it followed existing
> > > contours.
> > > 
> > > hwp_boost_hold_time_ns for example is a hardcoded 3 ms, and schedutil's
> > > iowait boost decay is tied to TICK_NSEC, with no knobs for either. The
> > > 300 ms decay is sized so that a render thread which is only 50-80% busy
> > > from periodic vsync and GPU-fence waits holds the boost across its whole
> > > busy period at a couple of CPPC_REQ writes total, while an idle core
> > > sheds the boost well before it can matter. The energy exposure of a wide
> > > window is small because EPP only influences behavior in C0 and an idle
> > > core sits in CC6 regardless. If folks want me to make these tunable I am
> > > happy to expose them.
> 
> In a lot of ways I feel like you're fighting with the hardware (and active
> mode) by doing it this way.  Did you look into using passive or guided mode
> instead?  They might be better suited for what you're trying to do.

I didn't try passive or guided mode, but I did try raising min_perf to
nominal on busy cores in active mode (with a restore on the idle path)
just to see what would happen. That reached the same 3.5 GHz median but
regressed frame-time p999 by 13-21%, per the numbers in the cover
letter. I'm happy to test guided mode out and see if I observe the same
issue. Passive mode w/ UCLAMP_MIN I also haven't tested at all, but I
will.

R.e. fighting the hardware, I think the concern is valid, though I do
think there's some precedent given that Intel has their hwp_boost thing
(though as Prateek said it's a bit different than what I'm proposing as
they don't muck with user-programmed EPP hints). The way I rationalized
it is that EPP is the hint interface the hardware gives us for exactly
this kind of bias, and the boost only moves it temporarily for cores
that are demonstrably busy. But active mode wasn't really designed with
this kernel-side dynamism in mind, so I'll defer to you folks and Rafael
on whether this is an acceptable shape for it (or whether Prateek's idea
of possibly having the active-mode drivers support dynamic governors
would make sense).

Thanks,
David