[Bug 217931] amd-pstate lacks crucial features: CPU frequency and boost control

[bugzilla-daemon@kernel.org]

https://bugzilla.kernel.org/show_bug.cgi?id=217931

--- Comment #22 from Mark Haun (haunma@keteu.org) ---
I repeated Artem's test on 6.7.0-rc6 (Void Linux with custom kernel---a bit
old, sorry).  My energy performance preference is set to "power".  I think I am
seeing roughly what Pedro describes.  Writing twice to scaling_max_freq is
definitely doing something, at least if we believe the numbers reported by htop
or cpupower.  Usually I cannot keep all of my cores (7840U) at 400 MHz; the
active ones are habitually between 1-3 GHz.  After following the above recipe,
the active cores seem limited to ~544 MHz instead.

(Although, since the amd-pstate-epp driver reputedly does not allow setting
limits at all, I suppose we should consider the possibility that these reported
numbers are incorrect ;)

It would sure be nice to have the non-determinism (i.e. bugs) ironed out of the
driver first, then consider supporting scaling_max_frequency.  I am actually
open to the idea---in principle---that the EPP stuff obsoletes max_frequency,
but I have to say, the entire scale is still biased too far towards
performance.  There ought to be a way for the user to basically tell the system
"POWER POWER POWER above all, and I really mean it!!" but as it stands, the
furthest that we are allowed to push things is still fairly weak:  any core
with the slightest activity is immediately boosted way up, so even an "idle"
system constantly has a few cores way above idle speed.  This might be why
folks are asking for a frequency cap.  Why isn't EPP more of a logarithmic
scale, where both ends of the scale are so ridiculously overkill that most
people will want a setting closer to the middle?  *That* is how it should be
designed.

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are the assignee for the bug.