power management and cpu governors :)

[wizard10000]

Wanted to comment on deb-fan's CPU governor ideas but the thread got locked when it went off-topic so I'm gonna pick it up here

I run my CPU governors wide open and here's why - a given task will take X number of clock cycles regardless of clock speed and within a given CPU architecture will draw roughly the same amount of power.

So - this is just my opinion but I really think that CPU throttling to save power isn't nearly as effective as chip manufacturers would like us to think - I may use twice the power but can complete the task in half the time. Again IM frequently less than HO on laptops the major issue is cooling, not power consumption - my Haswell i7 laptop bumps up against the processor's thermal limiter and throttles back even when DKMS is compiling a new video driver, which takes about 15 seconds

Modern processors spend more time waiting on I/O than processing, so within a given processor architecture I don't think clock speed matters much in terms of power savings; the CPU is either idle or it isn't and the number of clock cycles required to complete a task is fixed.

Anyway, that's just my opinion. Civil discussion appreciated

[CwF]

It's to big a subject that after a whole page of details, it's only applies to a few.

What you say is somewhat true in older generations under light single user loads. Past that the lowest clock to get it done does save power. There are many gotchas concerning things that need clock and don't get it, and things that demand full clock and don't need it. So a case by case thing.

[wizard10000]

...Past that the lowest clock to get it done does save power.

If the number of cycles required to perform a task is fixed, how does a lower clock save power exactly? If clock frequency and power consumption are linear within a given CPU architecture (they are) doesn't running a slower clock just take more time to get the same job done?

[CwF]

Total power does need to be a product of time. A job done slower means longer, longer at lower power may still be the same as higher faster, or similar. That's your point I think.

Basically if you graphed 'power per cycle' against clock you'd find the graph isn't flat. It goes up with clock. So without numbers handy, 10M cycles at 1.2 might consume a watt over a minute. Linear would expect 2.4 to take a 2 watts over 30 seconds, and maybe 3.6 would be 3 watts at 20 seconds. However it doesn't work out like that. I've found 2.4 might be close to linear or even better, like a watt over 25 seconds or less than a watt for the full 30 seconds. 3.6 goes the other way, more like 4 watts for the 20 seconds.

It follows in many things where there is a relatively fixed baseline requirement to be 'on' without any work getting done. As more is done, that baseline loss fades into the background and efficiencies go higher. Then at some point, some loss principle takes over and the curve is no longer in favor of more is better. For a cpu, as voltage increase, loss increases, period. This is why we now run volt cpu's and not 5 or higher like we used to, and all the components have gone this direction for this same reason. Building custom stuff we need to pay attention to these generations, 12 to 5 to 3.5 to 1.5, all doing the same thing.

Your view, wizard, will seem correct until you get the overall idle% under 99%. When work loads are such that there is something else to do while something is waiting on I/O, and the idle% falls to 0, or lower than 99% then the differences show up. For a single user doing one thing at a time a modern machine never leaves that baseline 'on' power influence zone, regardless of clock.

I don't want to get into other analogies and get the thread locked, but trains planes and automobiles have the same issues. Everything has a cruise speed that is the most efficient, it's not zero or full throttle.

Look at 'cat /proc/loadavg', particular the slash numbers, maybe 2/500. Get that number to 10/1000 (arbitrary bigger numbers) and then start testing and the results will be clear. <3/500 or so the average quad core has not left far the baseline power consumption.

I have machines that can run handbrake and make it feel like a background process. It doesn't even use all the cores. Same generation, 6@3.8 is exactly half the speed of 16@2.4, at the SAME power, maybe my most obvious example I actually did measure. I did include my earlier gen 8@3.9, it's a third faster than the 16@2.4 while consuming nearly TWICE the power. Not linear at all. All real cores btw, no hyperthreads.

So when I show you, you might say 'But I don't do that'. But I do, which is why we're both right.

[Head_on_a_Stick]

Thanks for this thread wiz, I've just added this to /etc/rc.local:

Code: Select all

for n in $(seq 0 7)
do echo performance > /sys/devices/system/cpu/cpu${n}/cpufreq/scaling_governor
done

I don't care about power saving

[CwF]

Ya, I guess I didn't comment in terms of powersave vs performance. The performance setting does eliminate that lead in consideration and lag in clocking up, we're already there! It does help. On the other hand, a single app running somewhere asking for clock on a more complex system satisfies the need for clock request, at which point there is ZERO difference between the settings. On a system that does actually idle, 'performance' will be more responsive.

Also check the directory hoas mentions, on many older systems there may be down_factor, up_threshold, ignore_nice_load and the easiest don't care setting scaling_min_freq, why mess with the governor when you could just up the minimum. You can echo into all of those. Yes, you can run a core or a socket asymmetrically form others in the same system. Yes, if you use threads you can mod their clock independently. So the governor is just the beginning. Add in the bios mods and you can create lots of interesting things. My 4@3.9 xp box does hold 3.9 on 4 cores (2 dual core actually 2x4c8t) all day without a fan, it's indeed snappy. You can create a setup that's never mid-clocks, either a low idle or near max turbo without ever floating in between.

[Hallvor]

CPU throttling makes sense if you want to avoid excessive heat and fan usage. The CPU isn't the only thing drawing power.

[Deb-fan]

HOLY CHRIST, this is bad even for me but had a bunch to say, fark!

Chapter 1:

DAMMIT, have to comment on this, as it's one of the more relevant threads on this subject I've ever seen kicked around in a nix forum anyway. Plus ... it's scary, actually somewhat understood what CwF said and learned some stuff from it. So thanks, Wiz10k for start and CwF for sharing some of your nix mad-scientist know how.

Just set it at performance ... who cares ? People that actually want to know how this stuff works, thus how to get best performance out of procs and learn to actually control it. Same reason I spent HUGE amounts of time getting to the point of being able to meaningfully compile my own kernel and mostly understanding what's important to dork with in config'ing it. The kernel is the heart of the gnu/Linux OS, the thing between the hardware/OS system and userspace. As are cpu(s) long considered the heart of any given computer system. While chips are built to stand a whopping, mostly end up in a landfill while they're still totally viable chips. Unless CwF see's them and wants to mess with it. Guy could probably daisy chain every proc that's ever been pitched in the trash together and have a setup capable of the greatest computing performance and highest speed processing that's ever existed.

Still without understanding this type of thing a person doesn't know how to get the full potential out of their chip(s) either. Can just end up wasting power, experiencing excessive heat and wear and tear, no net gains for doing it. Also don't care about power saving, do about pointless heat and first and foremost performance. Are plenty of things people can do to deal with getting more efficient power management while on battery. Many software packages which can adjust on-the-fly. Main one in my view would simply be turning down your screen brightness. The screen is a main culprit in sucking on a persons battery.

Anyway ... oddly agree with mostly everyone here. Everybody has a point, well ... in this case except for Head_on. His approach of just hey, I'll floor it, be sure to get my due performance. It's not anywhere close to being that simple. Someone can take it much further still than clock, interested parties of course do so, with info on the topic shared freely. Factors such as a processes priority, re-nice, cgroups or much other software made to control this, core pinning and core affinity(to take full/best advantage of a proc's caches, cores and threads), whether the kernel is config'ed to be preemptive or not, it's timer interrupt freq (1000hz vs 250)and such. The kernel is the gateway between everything that goes on in a gnu/Linux OS and the underlying hardware, stuff like even the actual quality of software-code someone is selecting to use. If the kernel someone is using isn't setup right, then they're losing out on performance could very well be (ARE)experiencing detriment for no gains just cause they never bothered learning what's what.

People who are obsessed with over-clocking. Which yeah is cool and I should've studied or used it more. It's friggin cool they can take a much cheaper cpu and make it run as fast or faster than one that's generally considered better. Big part of being an uncontrollable optimizer for me. Not just the cost savings. It's taking less and being able to rig it to outperform folks with so much more resources on-hand. Reason why I'm posting here, what CwF said made me realise something I knew but didn't sink in until right then. Yep ... someone can easily enough set this stuff by core (by disk drive, by network interface udev rules, etc etc)and tune it likewise. Just noting it and will certainly get around to dorking with it more but it's weird and nuts how much fine grained control the gnu/nix platform gives people!!! Woah !!!

Set xyz-power governor or freq on X-core, something else on others. Pin this or that process to using a specific core(s) and set limits on how much it can use. Friggin amazing how people managed coming up with all this !!!

I have a systemd service which executes a script, at an appropriate stage during boot ... in my case for this thing "multi-user.target". Just echo's varied adjustments for these type of things to files, sets ondemand, tunes it as best I've been able to understand in terms of performance benefits, though it's something somebody can find themselves endlessly fiddling with. Have done the setting a higher minimum freq, all of a simple echo value_someone_wants > ... to relevant file. Also dorked with some points in-between and capped my cores out at a freq lower than they were capable of just to avoid heat but didn't see the point of having a dual-core capable of @2.17ghz and never letting it use it. Settled on what I think is working best, for my hardware and usecase, at least for at the moment. Because this type of thing again is ... subject to change (with or w/o notice)... endlessly.

After monitoring activity on cores, how I tend to use this system in it's role. My cores are staying idling @ lowest freq ( 1ghz) over 90% of the time. So just adjusted things so that when they're under-load, they actually hit the gas pedal faster than in the ondemands defaults, stay on it bit longer but when not needed throttle down and therefor run cooler. Having them max'ed out won't do much of anything productive for me in this usecase. Needless heat(wear and tear), yes has to be whatever higher power consumption for the same workload but if you check cost of power even running an avg pc 24/7 year round ( and I have checked), it's negligible. Plus fan noise roaring during use etc etc and getting nothing out of that. Ninety-two percent of use time, it'd be a waste here. Again ... someone could get better gains out of a lower freq proc by tuning the kernel, over-clock, setting process core-affinity and priorities etc blah, than someone with a faster chip. Of course all of which takes effort to learn about.

However knowledge is power(or can be aggravation)too. I WANT to understand how this stuff works on deeper levels, thus possibly be able to tune for best performance and ideal efficiency etc blahblah. "Just floor it" is good enough for ignorant types. Like having a sports car, taking out on the road, whamming it top-end, without knowing where you're going, or in circles, using gas and putting needless wear and tear while not really accomplishing anything or getting where someone wants to go. Much less getting the most potential out of that hardware. Tuning an auto is a very technical matter too (or can be, again for people who bother to learn/understand what's involved. Have only ever vaguely researched that topic.) Can make all the difference in the world in terms of performance + benefit of having xyz-hardware to work with. In the right hands, it could blaze. Wth a Ford gremlin that can do 0-84mph in 2.2 seconds and gets 64mpg fuel efficiency ?!??!

What's learned on that one system/auto, is applicable to the next one someone buys. So clearly any knowledge and skill gained, can be a lifetime benefit.

Had to end with a mechanical analogy, yeah ... hope it's allowed too. No close, delete, afterall wouldn't want people posting stuff, having convo's and good natured banter in the offtopic section of a forum afterall !!! What's next, cats and dogs living in peace ?!?!?! OMG, what UNTHINKABLE madness is this !!??! Please close this immediately !!! Anyway again ... need to stop coming around here, some of the nixers which hang around say interesting stuff and dang near compels me to add my 2 cents. Thanks to whomever too. Had actually never really considered the fan's impact, in terms of adding to power comsumption or poss inconveniece of noise. Can get on someone's nerves, being a fanatical tweaker do tend to notice whenever it kicks on and if doesn't die down in a reasonable time, yep ... time to pop open a terminal and see what's going on in "top".

Lol ... of noes ! Am confuzzled now. Can I discuss power consumption in relation to this subject ? Do I need to file for a permit or exemption perhaps ?!?! Go before a commitee ? Anybody got the passwd to the database which lays out all the nuances of exactly what and which thoughts-expressions are allowed in offtopic in this forum ?

[Deb-fan]

Oops, thought of something, running system 24/7-365 and w cores at Max freq, personal cost in terms of paying the electric bill is neglible. Add that up for comps world-wide though, no doubt actually probably has a real ecologic impact. This carbon footprint, fossil fuels junk. Sighs, it's said the devil's in the details. Tend to dwell on this type of stuff. Esp anything I've got a real interest in and yeah gnu/Linux can be like friggin heroin!

[CwF]

It's amazing but goes against the we're all going to die mantra. If you look at Power Use per Capita the world has made extraordinary gains in efficiency over the last decades. It's the denominator in this expression that is the problem.

[Deb-fan]

Interesting point CwF, helps put things in a positive light. You must be a fellow thinks-too_much'er. Now that ya mention it is really cool how much progress must've been made. Back in the day, nobody gave a friggin, remember researching proper weatherization. Some info said the avg house had the equivalent of a 2 x 2 sq foot opening in it, if you add up all the cracks and seams etc. Around doors, windows, points where diff materials join. Sheesh peeps have taken to installing gaskets around power outlets and stuff on exterior walls! Errr, how does this relate to cpu freq's? 1. Just clearly the same increased interest in making pc electronics more energy efficient is prevailing now and 2. Who gives a crap it's off topic.

@Wiz10k, you mentioned over clocking in another thread. Assuming the practice is alive and well today? Curious what realistic clock gains you've seen? How much, is realistic w/o damaging stuff? Long ago, which is last time bothered looking into Oc'ing Intel was cracking down. They logically enough weren't wanting smart folks figuring out how to take an @2ghz and getting it to run @2.3-5ghz. Guess were afraid too many would start doing it. End result was you needed xyz-model chip(s), this Mobo, chip might explode at x-speed if you try to over volt them. Just seemed too complicated, risk prone and was too lazy to want to bother. Still thanks for bringing it up. Still think it's really interesting and cool.

[stevepusser]

Modern processors essentially shut themselves down when they aren't doing anything. (C states) There are different levels of this, and the goal of modern power managers and kernel schedulers is to maximize those halt states to save power without reducing performance. https://drive.google.com/open?id=1tAWTx ... rMIKVjJcsk

Instead of overclocking, I use undervolting on my two modern Intel laptops. That actually increases the maximum sustained speed on one under full load from 3.2 to 3.6 GHz (like when compiling a kernel with all cores), due to decreased thermal throttling, also with benefits of lower temperatures overall and increased battery life. I don't know why more people don't do it, though I've only used the iuvolt script for somewhat recent Intel CPUs, and don't know if the equivalent exists for AMD processors.

Maybe some contrarian can come up with something to say against undervolting--I make the challenge!

[Deb-fan]

^ Woah, that's really cool Steve, thanks .... and nice gain too. Am sure I recall people mentioning undervolting but didn't have any idea why. Also appears Intel isn't tripping out about this type of thing anymore? Vaguely remember the real reason for that crackdown I was mentioning wasn't them worrying about end consumers being able to get higher speeds out of lower cost chips, think was because unethical oem's at the time were setting up oc'ed systems and selling them as if they were higher spec = higher priced. Regardless dam good tip Steve and good thing for you, you get a higher clock and lower temps to boot? SCORE! Is the process involved in doing this overly complicated?

Makes sense that it could hurt their brand. Was a long time ago but oc'ing came with temp issues and risk of blowing the chip, esp if people tried to take it too far. Still an odd sounding thing from an engineering perspective, get higher speed at lower voltage? Sounds like Intel went another way with blocking people from prematurely frying their chips. Guess end of day who cares, people with the tech savvy can still get a nice chunk gain for investing some effort. Good deal.

[CwF]

It comes down to 'binning'.
Sometimes a particular cpu is tagged a particular sku because it can't achieve the next level. Sometimes it's tagged with that sku for marketing, aka supply and demand, and that particular spu might be able to achive the next level just fine. But, alas, it was loaded with the microcode of the lesser sku and sent out anyway.

Remember, most skus within a family are the exact same chip. The perfect chips get the best sku, and are a portion or even a minority of production. Lesser sku's were not intentional made lesser, they're technically flawed in some way and tested to find the flaws and then binned accordingly. On a good run, there are more chips meeting top specs. If the market doesn't absorb the higher production, they are tagged as lower skus to meet market demand, instead of lowering the price as the better chip and comprimising their pricing power. The OC people have identified many of these over the years. This involves flashing gpu's as a similar case. Overly detailed binning is expensive.

Castrating Xeons like I do does not take advantage of this fact. I start with the top bin and reduce, maximus overkill.

Undervolting, and over clocking, does take advantage of this mis-binning. There is an engineering reason not to undervolt. It will increase amperage around the socket in the local vrm area, but any decent board can handle this especially if it is spec'ed for higher sku's already.

Either approach, UV or OC, will work on some majority of examples. Particular sku's will be identified as more or less tolerant. If you tried hundreds or thousands of chips within a sku, you'd find a few that fail. To my knowledge, only AMD has released chips that are over promised and fail to meet the marketing hype. Intel usually leaves lots of headroom.

@stevepusser, check the voltage while at max clock? It's probably maxed. Starting out lower is similar to turning off cores or threads. The lead in to clock rate is set by voltage in a way similar to 'voltage divider' switch. As the clock rises amperage goes up, it is this in a feedback way that gets the clamp. So with a voltage to clock table adjusted you're creating headroom. That's headroom the chip might, or might not have, most do. I don't know whether an undervolted chip at some point hits max voltage, that would be an interesting detail...?

My overkill approach does the same thing in a different way. With something disabled, more of the legit power is now available for the remaining package. So a few cores will hit max and hold it without the need to feed the cores and threads not being used, and higher averages achieved. =Also creating headroom in the total power envelope.

So, find the headroom yourself by rolling the dice overclocking or undervolting. Or, start with known high-headroom part and extend it from there...If it were a vehicle, add power or reduce weight, same thing. I reduce weight, starting with the biggest engine. Stock power with lower weight is more reliable. Or, we could be negative and claim my Xeons are underachievers! I say they will underachieve 'til the end of time. Some little vrm will never go pop.

[wizard10000]

This is a great discussion - thanks, guys

[wizard10000]

...I use undervolting on my two modern Intel laptops.!

Would you be so kind as to share how you're doing this? Got two Dell Precision laptops I'd love to undervolt

edit: nm, I think I found it. intel-undervolt is the package I'm looking for

[Head_on_a_Stick]

Maybe some contrarian can come up with something to say against undervolting--I make the challenge!

The relevant ArchWiki page has a rather prominent warning:

Misconfiguration of CPU voltage settings might result in permanently damaged hardware.

https://wiki.archlinux.org/index.php/Undervolting_CPU

Do the compilation times actually decrease when your laptop is undervolted? A higher clock speed might not equate to faster compilation if the processor functions inefficiently at lower voltages.

I've only used the iuvolt script for somewhat recent Intel CPUs, and don't know if the equivalent exists for AMD processors

https://github.com/kevinlekiller/amdctl/

[stevepusser]

...I use undervolting on my two modern Intel laptops.!

Would you be so kind as to share how you're doing this? Got two Dell Precision laptops I'd love to undervolt

edit: nm, I think I found it. intel-undervolt is the package I'm looking for

I use the iuvolt script. https://github.com/tiziw/iuvolt

The processor has to be at least Intel third-generation. You do have to turn off Secure boot. You can use the same undervolting settings for your laptop as others have for ThrottleStop on the Windows side, if you can find them on the Net, such as at notebookcheck.com forums. That lets you skip the trial and error stage of finding the right settings. I managed to do some hacks to also get it to autostart and restart after resume without systemd on both laptops for MX, though I have to first run i7z in the script for a couple seconds on the Skylake machine before it accepts those changes in the MSR registers. Running i7z will also let you watch the VCore drop after you successfully undervolt, and pulls in some of the necessary packages for iuvolt--the other is bc.

Yes, the MSI's laptop increase in speed results in better performance and faster compilation times for me. The same results on the Windows side is why Throttlestop is quite popular there among gamers and others interested in performance. Luckily, I never had any trouble recovering after a freeze when experimenting to find the lowest safe voltages, but YMMV.

[Deb-fan]

BIG +1 dang good thread, thanks for sharing some of your know-how guys.

Think it's just easier to include disclaimers on everything and whose to say the person writing up x-wiki entry even really knows all that much about it. Encountered endless warnings about oc'ing (some extremely dire, no doubt most strongly phrased by people who didn't even know what they were talking about.) However didn't keep people from doing it successfully for years on end.

First started interacting with CwF, thought he just had odd preferences in how he rigged hardware. Also thought he was making up his own language. Now becomes clear he just really knows his stuff and can somewhat follow along with what he's saying.

Stevep also clearly someone whose got it together and obvious how often he's compiling, backporting packages endlessly for the rest of users. In my understanding a factor in this (compile time) would again come down to kernel config that's selected, 100hz vs 1000 and non preemptive, which most stock kernels from repo come 250hz + voluntary preemptive. Other kernels available in repo's w different config options used. Someone can obviously install some for spec uses and just boot that one as needed, ie: performance kernel for general desktop use and another better setup for throughput while compiling. Just wanted to learn how to custom compile my own. It's got all my preferences used.

[stevepusser]

I use the Liquorix kernel, but I really don't think that makes much of a difference in compiling performance; certainly the higher speeds I can run via undervolting make much more of a difference. Right now, I'm trying an experimental backport of gcc-9 9.2.1, which keeps all 12 threads at 100% and 3.6 GHz for hours and hours at a time--I'm trying the final builds with the self tests enabled, which maybe triples the build times--don't know for sure, as the first build is still in progress.

I do boost the kernel frequency to 1000 Hz on my own backports of the upstream Debian kernel, like here on the OBS:

https://build.opensuse.org/package/show ... source-5.4

That turns out to be easy to switch by editing debian/config/config. But more complicated kernel configuration might involve other settings that aren't so easy to just edit in. You can also see that building a Debian set of kernels needs a lot more time and disk space than a simpler kernel build like Liquorix.