Extend your battery life with scx_rustland | Hacker News Reader

Extend your battery life with scx_rustland

arighi.blogspot.com

84 pointstodsacerdoti19 comments

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.

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

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.

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.

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.

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.

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.

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.

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!

Just another way too much heat can threaten your ONI run :)

Race-to-idle is sometimes a goal, yeah; if you have some performance budget (say, a 16ms time slice), and a fixed workload, does it make sense to run resources at lower power and barely meet the budget, or to run everything at max power so they can spend the remainder at idle? The answer is different for many scenarios.

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.

Unsure if parking the core is always the right move. There's many scenarios where running multiple cores at lower clocks/finishin faster would be net positive. The benchmark is really promising though! Would be great to see some Phoronix testing of this.

20% improvement is nice... but Linux laptops are like a factor of 4-8 behind Macs, at least without a lot of tweaking. I was in a Google Meet meeting on mine (mid-to-high spec Dell) and it lasted exactly 1.5 hours.

Feels like there are bigger issues than the scheduler.

TPM enabled?

I guess so, it's only a couple of years old. Does that make a difference?

Its night and day for me.

I think its enabled by default on Fedora and maybe Ubuntu, but definitely not on Debian, Arch or Guix.

Worth a try at least. Though based on the fan speed while I'm in meetings I reckon it might be more to do with missing hardware video acceleration in Firefox or something.

That sounds like the browser isn't doing video codec offload to me.

Reply on news.ycombinator.com