Schedutil Frequency Invariance Revised For Better Intel Performance + Power Efficiency

[F.Ultra]

On Android, the reason for so many governors is they tie in Android stuff to the governors like tap the screen and it'll ramp up or force it to stay on its lowest freq if the screen is off and stuff like that. Some of them do some interesting things and are pretty neat; though most of them are unnecessary and are just some random person's fun project to learn C and kernel development.

I'd reckon that none of them are worth using in regards to desktop users....some of them may benefit laptop & tablet users since most Android governors are designed around trying to balance saving battery life and overall performance.

And let us not forget that this field is ripe for placebo effects right and left.

[skeevy420]

And let us not forget that this field is ripe for placebo effects right and left.

Yep. That's why I think load based tools and daemons are better.

Welp, we're pushing a full 10gbps, better ramp up the CPU to keep up with SHA512 check-summing and Zstd compression or ffmpeg and the media transcoder just finished, should wait a minute before ramping down in case a 2nd video is picked on the Xbox.

Governors really don't need that kind of stuff, just interfaces to adjust what happens overall or to tell it what to do right now and to stay that way until further instructions are sent.

[F.Ultra]

Yep. That's why I think load based tools and daemons are better.

Welp, we're pushing a full 10gbps, better ramp up the CPU to keep up with SHA512 check-summing and Zstd compression or ffmpeg and the media transcoder just finished, should wait a minute before ramping down in case a 2nd video is picked on the Xbox.

Governors really don't need that kind of stuff, just interfaces to adjust what happens overall or to tell it what to do right now and to stay that way until further instructions are sent.

Hard to do right though. Ramping down to slow and you waste energy and heat, ramping down to fast and you end up with the Ondemand problem for games that was the basis for the Feral GameMode module. And that is just one of the many variables.

[mrugiero]

The problem with more and more configurability is the governor gets to a point where it spends more time running checks and balances to decide what to do than actually doing it.

It depends on the configuration and how it's implemented.
If it's just a number that it already has to check, then it's probably not as expensive.
If it's changing a function call, you can settle on defining that on boot time, which allows to replace the call on site, not requiring indirection (that's call static calls AFAIR).
More complex changes probably justify a different governor altogether.

Governors really don't need that kind of stuff, just interfaces to adjust what happens overall or to tell it what to do right now and to stay that way until further instructions are sent.

You end up with the exact same problem, you just moved it around. Who tells it what to do? What logic does it use?

[skeevy420]

It depends on the configuration and how it's implemented.
If it's just a number that it already has to check, then it's probably not as expensive.
If it's changing a function call, you can settle on defining that on boot time, which allows to replace the call on site, not requiring indirection (that's call static calls AFAIR).
More complex changes probably justify a different governor altogether.

I agree...but, once you add hundreds of numbers to check, those need their own priority checks, etc which does increase the complexity. It's one of those situations where the governor should ideally do it all, but due to the complexities of modern computing, that isn't very feasible and all the complexities defeat the purpose of simple, general purpose governors.

You end up with the exact same problem, you just moved it around. Who tells it what to do? What logic does it use?

That depends on how it's implemented. What I'm imagining is a system that supports hundreds and thousands of different things to get and it would only scan for the preconfigured values the user sets in a plain text config file. As long as the user doesn't go full-on stupid with hundreds of checks, the overall impact would be negligible. Priority could set based on how high up it is in the file with Python-Inspired formatting for underlying checks...so if Check 1 is false, its sub-checks don't need to be done.

Check 1
    Check 1a
    Check 1b
        Check 1b-1
    Check 1c
Check 2
Check 3
   Check 3a

All I know is we don't need to go the Android route where a new governor is created for every single different workload and workflow when all we need is a daemon to tweak the up and down thresholds while X is running or to lock the freq to max while Y is going on or to prevent the governor from ramping up while we're in a state of Z.

[skeevy420]

Hard to do right though. Ramping down to slow and you waste energy and heat, ramping down to fast and you end up with the Ondemand problem for games that was the basis for the Feral GameMode module. And that is just one of the many variables.

Exactly, that's why it should be user configured instead of just relying on current CPU values. The gov doesn't know why the CPU just ramped up or down, only that the user did something to cause that so it acts accordingly.

Instead of running a script before launching the program to set the down threshold to 1/switch to performance and another script to revert that upon close, a user configured daemon could automagically do that.

The OnDemand problem for games is why I suggested a mouse movement check above....just because I'm corner camping with a shotgun in a building and there ain't shit going on currently, that doesn't mean I want my CPU to idle down so I can get shot up by some MLC asshole because my idling-ass CPU didn't ramp up fast enough to render The Flash with a pistol and knife coming through the door...

[jwh7]

Fyi the 'real' v5 was posted yesterday and is getting tested for merge to tip.