switch default cpu governor to schedutil #6120
Conversation
lanefu
requested review from
rpardini,
chainsx,
AGM1968,
PanderMusubi,
Tonymac32,
krachlatte,
schwar3kat,
teknoid,
viraniac,
sgjava,
brentr,
Manouchehri,
TRSx80,
ahoneybun,
amazingfate,
catalinii,
joekhoobyar,
paolosabatino,
efectn,
igorpecovnik,
ManoftheSea,
SteeManMI,
adeepn,
monkaBlyat,
pyavitz,
echatzip and
hzyitc
as code owners
github-actions
bot
added
size/medium
There was a problem hiding this comment.
I like the schedutil idea and approve it, but I read it still has some performance issues versus on-demand: https://www.phoronix.com/review/schedutil-quirky-2023
Perhaps they are niche cases, but maybe some benchmarks with sbc-bench are worth it, at least for curiosity, since things may have been changed in kernel 6.6 with EEVDF in place of old CFS scheduler.
Would need to modify SBC bench as it turns governors to performance when executing |
Did some benchmarks... there's plenty ways to split hairs but my own conclusion is that schedutil + irqbalance gives us good out of box performance without having to worry about maintaining armbian-hardware-optimize |
|
Quoting https://docs.lane-fu.com/s/ZclNlyJQe#SCHEDUTIL-Governor
Nope, the way Geekbench executes the tests is that flawed that it's almost like adding some randon numbers to the results. You need to run this tool at least 10 times in a row to get anything you can work with (not even blindly averaging all results helps since sometimes you just see that the test execution itself has an influence on performance and you need to forget about the first 2 or 3 runs). See for example the 10 'Raspberry Pi 5 Model B Rev 1.0 (3.08 GHz)' entries here at the top: https://browser.geekbench.com/user/tkaiser (5 times And see this explanation
Nope, what your 6 fio tests really show is this instead:
As such you will have done some further checking what causes "armbian-hardware-optimize enabled" resulting in slower MMC benchmark scores, maybe the Asides that no idea how these two benchmarks each executed only once per 'setting' in 'fire and forget' mode should be able to justify any performance assessment wrt cpufreq governor? Have you compared with It seems this governor switch is only based on feelings and quoted documents that are +99% based on situation on x86, right? And even if I know that none of you guys cares about such stuff: congratulations, you completely ruined Armbian NAS 'performance' compared to 2023 settings with this single change: https://github.com/ThomasKaiser/Knowledge/blob/master/articles/Quick_Preview_of_ROCK_5_ITX.md#cpufreq-governor-schedutil-dmc-governor-set-to-dmc_ondemand-armbian-defaults-with-rk3588-today Would be fair to announce Armbian not caring about 'energy efficient server stuff' any more (unlike a decade when this was the primary goal) but only about 'Desktop Linux' or whatever today. Though I know that won't happen too |
|
@ThomasKaiser this would all been valid and fruitful discussion had you engaged during the PR's lifetime -- now, necro apart, please be respectful; the change is in as it was the best solution we (however poorly) evaluted, being generic enough. Your "NAS" use-case, albeit common, is not the only one. The main problem here resides in the fact that the relevant changes/settings are either in kernel configs/patches or in a monolithic 1990's style single script filled with conditionals -- which ofc has become completely unmaintainable, and to which you've never proposed architectural changes, only more conditionals. So "congratulations" to you too. When I have enough cycles to spare, I'd look into how to make such settings easily doable in userpatches/extensions, so you can actually contribute to say an See you in a separate PR 🖖 |
LOL! PR sent on 31th of Dec, merged on 1st Jan. Even if I would be joining this project at this time of the year I spend time with family. And the stuff I have commented on (the benchmarking methodology) happened after the merge. But good to know that zero evaluation has been done how the switch to
I know very well and wonder which testing has been done to evaluate governor change other than 'I use this governor personally and am fine' and 'some doc says it should be better' (or in reality mostly related to And of course nobody will revisit the question the |
|
Just for laughs...
Holy cow. The real problem is not even a single member of 'Team Armbian' today wanting to wrap his head around this nonsense for a few seconds since nobody cares about this sort of optimization for 6 years now. This is the 'generic' approach for this 'problem': https://github.com/ThomasKaiser/build/blob/9c0bc9db7ac89d267911c8e1e981ceea447dcd78/packages/bsp/common/usr/lib/armbian/armbian-hardware-optimization#L75-L83 Works only for 1 to 100 CPU cores. In case you want to deal with more it's time to add another string
@paolosabatino appreciate that you even mentioned potential performance issues with this governor. But... this was on x86, this was Phoronix and why would this apply to the situation on ARM? Michael Larabel wrote:
How should this be possible: On ARM And the same 'logic problem' applies to the benchmark expectations. Switching cpufreq governor affects how clockspeeds behave in real world situations. How fast will they ramp up when a user moves the mouse (desktop use case) or copies medium sized files to a server (NAS use case) or will be able to answer web requests (web server)? Most benchmarks are pretty much unaffected by this since they try to fully utilize the CPU cores anyway which results in every governor (not being completely broken) in ramping up clockspeeds to the max. That's why you need to always test with Talking about the latter: another homework done for you @lanefu https://browser.geekbench.com/user/tkaiser And apologies for sounding rude as usual: I don't care. At least we have documented together Armbian having switched to an entirely different target audience (DietPi + desktop?) than in the past and the situation for people wanting to run a small and energy efficient server on ARM hardware is pretty much fucked up since crap like this will happen anytime again. |
|
Testing method: Testing devices: 2 SDIO connected MMC devices Testing host: Rock 5 ITX with 5.10.160 legacy kernel Testing focus: how does the 256 GB Samsung EVO Plus A2 / UHS-I/SDR104Reported by
|
|
I knew the armbian-selected io_scheduler that was the problem. I had originally intended follow-up with a 2nd PR to address a "simplification" of armbian-hardware-optimize. As we know, armbian-hardware-optimize is not maintained, and nobody looks into it. (Mild Exceptions being JetHome, Oleg at some point in the past, and I think an effort was made for some Rk3588) Inspired by prior feedback about getting rid of it since nobody maintains it--My real thinking was "can we simplify to some new sane defaults with good enough performance and live without it?" Then passionate people could then go add their own optimizations as they see fit. Or as Ricardo pointed out, a more intuitive mechanism for tying this things to a board configuration rather than burying into a monolithic script in the build system. There should have been more conversation. There wasn't. I should have finished the job. I didn't. I've been using an inelegant extension that satisfies my own concerns verified through extensive non-rigorous seat-of-the-pants unscientific testing. Yes I'm aware that irqbalance doesn't consider big little scenarios. Yes I'm aware that it's default setting is to periodically re-run and re-balance. |
|
I understand there's some intent woven in this conversation to teach some of the technical considerations, examples of testing methodologies, and demonstrate the creation of a good paper trail for later review. ...but that high-value information is hard to focus on as it mostly it just feels like being poked, hit on head with shovel, then handed a bunch of reports to read. This conversation leaves me exhausted and extremely uninspired. Going to do my best to not let it steal from my weekend. |
I guess you were talking about The most important part of Personally tested with I have revisited So what to do when Does it work? Is it future proof and works on any system? Sure, but the |
|
I was using schedutil for few years on aarch64 board, but reconsidered and went to ondemand as simpler, snappier and less-overhead governor. I don't see any profit in using any other governors if you aren't on battery power. |
W/o having a specific use case in mind IMO it's always hard to talk about those things. And we need to keep in mind that But for this to work properly (or in any reasonable fashion) prerequisits need to be met such as DT properties for cores like
Back in the days when I joined Armbian it wasn't called Armbian but known as "Igor's image" and the focus was primarily on small, energy efficient servers as such the 'design decisions' back then: servers idle a lot so we needed settings that kept consumption overall low but ramped up clockspeeds immediately when needed. I have no idea what Armbian is officialy about today (DietPi + desktop? 'Linux with desktop for people who can't or want to afford x86'? Something else?) but what I know is the decision to change default governor was based on zero evaluation. |
|
@ThomasKaiser makes good points - it's really about the use-case for the device. OnDemand is still a good default... SchedUtil is a second best estimate/guess... It depends on the SoC/Board and the purpose - and there, it's thermals, and the OPP's... |
@sfx2000 as mentioned before this scheduler needs some information about the cores in hybrid designs to work correctly. At the moment I would believe among the fleet of 'Armbian supported' devices |
|
Talking about proper properties giving RK3588 (A76 1.9 times faster than A55):
Amlogic S928X (A76 exactly two times faster)
Unisoc UMS9620 (A76 2.45 times faster than A55)
Google G1 (A76 2.5 times faster than A55):
Funny! We just learned that A76 and A55 perform differently based on which SoC vendor is using them. The most amusing properties are those from Amlogic of course, obviously the person having added those has no idea what this whole stuff is about and just decided to use a nicely looking Google/Samsung seem to have actually measured something while the 100/300 value pair from Rockchip for the RK3588 is obviously just a wild guess. The clear winner is Unisoc since they provide detailed power costs. But why do the Let's use the popular Geekbench 6 suite (though giving questionable numbers on any platform other than x86) and have a look at the A76 and A55 both at 1800 MHz in RK3588 (with the LPDDR at 4800 MT/s): A76 single-threaded 3.23 times faster than A55 at same clock: https://browser.geekbench.com/v6/cpu/compare/5841948?baseline=5842066 (full results)
3.2 times faster or only 1.9 times faster according to Rockchip's DT creator with power costs obviously not the result of any measurement but just 2 random numbers thrown into DT: good luck |
Description
The schedutil cpu frequency governor is more tightly coupled to userspace activity and performs more granular cpu frequency changes. I've personally be using it for years. I think it's prudent to change to this default.. especially given cpu-frequency utils is deprecated and no-longer enabled by default on armbian builds.
I think if this is merged it's an opportunity to also remove some of the unmaintained on-demand governor tweaks in armbian-hardware-optimize as well.
Quoting the kernel docs: