On Thu, May 15, 2025 at 02:45:13PM -0400, Ted Unangst wrote:
> On 2025-05-15, Vitaliy Makkoveev wrote:
> 
> > I like this diff. Without it my machine (dmesg below) with
> > 'hw.perfpolicy=auto' runs at 400 Mhz and can't be used for my normal
> > workflow. As the addition in the 'hw.perfpolicy=auto' sound is broken, it
> > plays the middle frequencies very quiet. This diff fixes it.
> > 
> > I don't like to use this machine with 'hw.perfpolicy=high' because it
> > does permanent cooler on/off with hight frequency.
> > 
> > So, I want this diff be pushed forward. Can someone from this area
> > provide feedback?
> 
> This is similar to the original approach long ago? That was flipped
> because it wasn't responsive enough, but I've lost track of changes
> since. Can you explain a little how it differs so we know it's not a
> regression? (I always liked the old algorithm, heh, I'm just checking
> we're not going to go back and forth.)
> 

I can't answer to the first question, but I can describe the current
behavior. Set hw.perfpolicy to "auto", start firefox, play something
from youtube. The hw.cpuspeed will be the most times 400, sometimes it
will be raised to 2501. No frequencies between the minimum 400 and
the maximum 2501, it will spent more than 90% times with 400. Sound is
broken. With this diff the frequency will permanently scale from 400 to
2501, the most times in the middle. Sound is not broken, I could say my
gnome session works acceptable.