[HN Gopher] Extend your battery life with scx_rustland
___________________________________________________________________
Extend your battery life with scx_rustland
Author : todsacerdoti
Score : 72 points
Date : 2024-05-25 20:13 UTC (2 hours ago)
(HTM) web link (arighi.blogspot.com)
(TXT) w3m dump (arighi.blogspot.com)
| jeffbee wrote:
| Pretty nice! I feel like there is a lot of room in this space for
| people to make choices other than the platform defaults, or the
| ones Linus Torvalds personally prefers. And there are a lot of
| optimizations on the table, for example on the hybrid Intel CPUs
| when an E-core cluster is running there's almost no marginal cost
| to assigning another task to one of the four cores on that
| cluster.
| viraptor wrote:
| I'm not sure sure if this is a joke given the Terraria test,
| where the game has very low requirements and it's locked to 60fps
| anyways. The potential max might've changed from 200fps to 100fps
| and the author didn't even report on the kernel compilation time.
| tux3 wrote:
| It's not useful if you're trying to measure the tradeoff, but
| it paints a clear picture for everyday use.
|
| If I'm just loading a web-page or playing a non-AAA game like
| Terarria, I don't care whether I get 300fps or 200fps. I do
| care if my laptop has 4h of battery life with 6W consumed, or
| 8h and 3W.
|
| There's another demo if you click through on the Github repo
| where they start a make -j32 on the kernel in the background
| while Terraria is running, and (with low-power mode off) the
| FPS actually goes up significantly compared to EEVDF, which I
| would definitely not have expected from a small plug-in
| scheduler in userspace like this.
|
| I'd definitely like precise benchmarks, but for a proof of
| concept, I think it's a very interesting demo of what's
| possible.
| viraptor wrote:
| Oh definitely, for a mostly idle system like using a browser
| it won't matter much and the energy savings are nice. But it
| would be great to know the trade-off because if you have 50%
| energy saving, but have to wait 2x the time, you're just
| wasting time.
| patshead wrote:
| This can be such a complex problem. Maxing out 8 cores is
| rarely twice as fast as maxing out 4 cores, but it will
| likely make the CPU draw around twice as many watts. That
| makes it seem like it might be a better use of power to
| keep cores idle during a big compile job, but it also takes
| watts to drive the display and keep the backlight on.
|
| I can't imagine this would be easy to get right, and it is
| probably much harder to set a good default. Even so, the
| background compile job taking twice as long might not be a
| waste of time as long as I get to play Oxygen Not Included
| twice as long!
| tux3 wrote:
| Just another way too much heat can threaten your ONI run
| :)
| teraflop wrote:
| Maybe I'm not understanding the explanation, but how is a policy
| of "never wake up an idle core if another core is running code"
| different from "only ever allow one core at a time to be awake"?
|
| The latter could be achieved much more easily without custom
| code, e.g. by using the cpuset cgroup controller to pin
| everything to CPU 0.
| fermuch wrote:
| I think the idea is something like "let things run normally
| until they don't need that extra core. If it doesn't need the
| core, we shut it down. And it never wakes up"
|
| Which... Makes it hard for the user to notice the change? Cores
| will naturally go offline, but performance stays the same while
| you still use it.
|
| I think this is just a demo of what you can do with user space
| scheduling and shouldn't be taken seriously...
| andrewaylett wrote:
| My reading is that it doesn't actually affect waking up of
| cores that have actually gone idle -- what it does is avoid
| _not_ idling a core because there 's more work.
| foota wrote:
| I think there's some other mechanisms that wake CPUs?
|
| This is just saying, if something decided to idle the CPU,
| don't wake it just because there are tasks waiting to run (let
| something else decide to wake it).
|
| E.g., if the system is overloaded for some period of time maybe
| it will wake a cpu in response to that, but a short burst in
| tasks won't result in waking up all the CPUs.
| fwlr wrote:
| Unsure on correct terminology but the comments in the
| implementation seem to imply that there are multiple CPUs per
| core (or perhaps multiple cores per CPU?), and the overall goal
| seems to be to ideally use just one of the members of each
| group, rather than spreading the load throughout the group.
|
| All that `low_power` seems to do is prevent members from being
| kicked out of 'idle' while another in their group is 'not
| idle'. This 'idle' state seems to be more of a guideline than
| the final decision, I believe if there is enough work to be
| done that it will get sent to 'idle' members.
|
| The best analogy might be: three guys are dozing on the couch
| (the idle state), while the fourth guy is either doing chores
| (the active state) or else standing around generally being
| awake (the ready state). As long as the total amount of work
| doesn't pile up past the awake guy's capacity, he will let the
| others keep sleeping.
___________________________________________________________________
(page generated 2024-05-25 23:00 UTC)