Announcement

Collapse
No announcement yet.

Schedutil Frequency Invariance Revised For Better Intel Performance + Power Efficiency

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Schedutil Frequency Invariance Revised For Better Intel Performance + Power Efficiency

    Phoronix: Schedutil Frequency Invariance Revised For Better Intel Performance + Power Efficiency

    SUSE developer Giovanni Gherdovich has sent out the latest patches on supporting frequency invariance within the kernel's scheduler code and ultimately making use of it for select Intel CPUs to yield not only better raw performance but also power efficiency...

    http://www.phoronix.com/scan.php?pag...-Invariance-V5

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

    Leave a comment:


  • skeevy420
    replied
    Originally posted by F.Ultra View Post

    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...

    Leave a comment:


  • skeevy420
    replied
    Originally posted by mrugiero View Post
    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.

    Code:
    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.

    Leave a comment:


  • mrugiero
    replied
    Originally posted by skeevy420 View Post
    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.

    Originally posted by skeevy420 View Post
    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?
    Last edited by mrugiero; 11-19-2019, 07:59 AM.

    Leave a comment:


  • F.Ultra
    replied
    Originally posted by skeevy420 View Post

    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.

    Leave a comment:


  • skeevy420
    replied
    Originally posted by F.Ultra View Post

    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.

    Leave a comment:


  • F.Ultra
    replied
    Originally posted by skeevy420 View Post

    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.

    Leave a comment:


  • milkylainen
    replied
    Originally posted by Slartifartblast View Post
    Well I suppose it offsets some of the performance degradations thanks to mitigations, a rare scrap of good Intel news.
    Especially since "Intel Inside" has become "Intel waste heat Inside"

    Leave a comment:


  • skeevy420
    replied
    Originally posted by timofonic View Post

    Then some of them have interesting features, your initial statement is wrong.

    I think CPU governors need a lot more configurability. What about eBPF for other tasks other than network filtering?
    Tying into Android features can't be neat and interesting? What are you trying to get at?

    I'm not saying that governors don't need more configurability, but I don't see how touchscreen frequency ramps and other such Android governor features help Linux desktop and server users; and I did say they'd be useful for Linux laptop and tablet users...Linux on a battery people.

    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.

    What's better, IMHO, are userspace tools, like Feral's GameMode, that are designed around specific tasks and can set the governor and frequency as necessary. Someone like myself might not need or want the governor to ramp up or down based on network-specific tasks and someone needing network based load monitoring might not want or need GPU load and mouse movement detection.

    Leave a comment:

Working...
X