Stefan Hagen <[email protected]> wrote: > Stuart Henderson wrote (2022-06-28 08:13 CEST): > > On 2022/06/27 17:12, Bryan Steele wrote: > > > > > > Shouldn't this also take into consideration hw.power as well? If it > > > doesn't make sense for perfpolicy=high then it probably doesn't for > > > perfpolicy=auto when on AC power? > > > > Why so? perfpolicy=high says to me, "I want it fast, I don't care about > > fan noise etc", but perfpolicy=auto (whether on ac or not) suggests there > > are considerations other than speed. > > > > perfpolicy=auto+AC sets perflevel=100, which is the equivalent > to perfpolicy=high. > > I believe this is a discussion we have other threads for. > > But in my opinion as long as perfpolicy=auto+AC sets max speed, it > should be the same as perfpolicy=high and not something "almost > perfpolicy=high".
The reason I changed it that way last year, is because auto was behaving on too many machines as dog-slow. I did not believe I could repair auto on my own, so I chose to create a reaction --- such that the whole team would work together on algorithm changes so that auto would once again be effective -- some sort of blend of desired behaviour between everyone. It should scale up performance as soon as it is required (not slowly, even now, I think it is too slow because it requires compute to occur slowly, which eventually bogs up the scheduler data structures, which eventually causes it to speedup, but in the meantime those first immediate chunks of compute happened in very slow mode). I think what changed in newer machines is that the gap between slowest and fastest is far greater than in previous machines, so choosing "slowest" and upgrading with such a pessimistic method is a bad idea.
