power management and cpu governors :)

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

[Deb-fan]

Not saying anything bad about Liquorix, no doubt guy behind maintaining it knows his stuff. No doubt more than myself. Of course tried it and liked it anyway. Was one of the ways I started out learning about the topic, installed various "high performance" desktop kernels and checked out the .config files used with them. Of course Liquorix was included in this process, he includes a bunch of patches and uses some config's I don't prefer or think best(for me.) Plus he's still got to cater to a wider range of usecases and preferences than I do. For example I remove support for varied filesystems I never intend to use which are ordinarily compiled into most kernels. End result yep, somewhat smaller kernel thus somewhat less memory overhead etc. So still when I have the opportunity prefer to compile my own.

NOTE: Such dorking with a kernel can be a double edged sword too of course. Remove support for ext2, later go to dork with ext2 and not remember it's compiled out of the kernel. WHY ISN'T IT WORKING !! AHHHHHH !!!!!! Lmao, been there ... done that, got the shirt and the shirt says "I'm a dumbazz who fiddled with my Linux kernel and forgot what I fiddled with".

Though yeah, when you want the kernel to focus on doing tasks with better throughput (ie: compiling) then lower timer interrupt (100hz) and non-preemptive is better. Same kernel .config used, higher clock-freq, then yeah, running same tasks at a higher freq is bound to get done faster, bound to get more done/faster.

Personally never been able to get much better than what comes set in stock kernel, yes some but nothing mind-blowing. Which is why you see almost everybody saying custom compiling isn't worth it and truthfully I mostly agree. Though obviously not fully agree as can be some benefits, faster boot, lower memory footprint, more responsive desktop apps, somewhat lower cores temps and load avgs. So still personally consider it worth doing, I don't apply anything by way of patches as I've still got much to learn on the topic. It's a one time thing in many ways or a couple times on a given system. The hurdle is all the time involved in learning what even matters as pertains the subject and that's CONSIDERABLE. Took me quite a bit of time/effort to somewhat understand and thus get any benefit out of compiling my own kernel. Really isn't worth it mainly, someone wants a higher performance kernel tailored to desktop and meant for better performing real-time applications then yeah, which many audio-video apps do work better w more appropriate kernel config's than what's stock. People want these things (and what desktop nixer doesn't) better to just install one from a trusted source and call it done. Which guess Liquorix qualifies it's been around and widely used forever.


At least check out what comes stock in the repo's. The time involved mostly negates any possible benefits from learning about custom config'ing kernels. I knew this, still wanted to learn about it and custom compile just for the sake of it, considering the Linux kernel is the heart of gnu/Linux. Also I'd gotten to the point of thinking tweaking kernel config's can't possibly be worth it, someone should just install a packaged high performance deal on desktop and get on with life. Apparently I'm wrong as a distro named Clear OS is somehow doing this. Seen folks refering to the config'ing and patching they're doing to the kernel as being like overclocking without having to set it up. It's kicking all hell out of other distro's kernel choices in Phoronix or whatever testing thing. I'm not at the point where I can really understand all involved but it's causing a stir in varied places and prompting discussion.

When comes to custom compile I have seen gains, again ... nothing mind blowing but quantifiable gains. I mean the output of "top", "uptime","ps_mem", lm-sensors, "systemd-analyze", how quickly applications load and their latencies/responsiveness and actually timing the thing to working desktop vs a stock kernel are not just someone's impressions or opinions, that data is indisputable fact. Recently came up with a saying for something I've long believed. Introducing my TTT rule (three-t rule), goes like this "Tuning without Testing is Tarded." Lol ... totally true all this I think it's faster/better, feels like it's faster crap is just that ... pure crap in my view.

Though kernel config and how something like affect or benefit as it's related to something like proc-core freqs are joined at the hip. Sheesh same as pertains to anything hardware and gnu/Linux, kernel's the core of it all. Again with the example of a real-time app or a process that needs cpu time and needs it NOW to work best. A kernel config'ed with non-preempt won't give it cpu-time when/as requested, will tell it wait in line with all the other processes, voluntary preempt might not give that process time. Imagine the likely impact on how well that app performs in this. Other ways to fiddle with it anyway, like when checking in terminal, the pulseaudio process is given a nice value of -11 vs the others.

[Deb-fan]

Chapter 19, errrr, forgot which chap I'm on by this point. Sorry to whomever, wouldn't blame anybody if they send me a cease and desist please sthu pm.

Guess compile time could be another factor. Though not for you peeps with more current specs, this old thing is cutting edge or was back in the late 1800's when it was made. So never mind, you decent spec people can probably compile a kernel in 15-20mins anyway or on this beast could just set the thing up, before hitting the hay, start the compile and let it do it's thing while I'm catching zzzzzz's. Honestly no point in chasing higher kernel versions on this old thing anyway. Folks with new hardware yeah would be paying closer attention to release notes and waiting for new features and better hardware support coming out in newer kerns. Ah no worries sure Liquorix and others keep convenient current versions within easy reach anyway.

Still think it's worth considering this, as pertains to cpu freq's, as it does to gnu/nix configs meant for desktop users vs kernels as they come configged stock. All this is of course a matter of choice and preferences for each of us nixer's to decide what we prefer most. Arghhhh, getting on my own nerves. Gotta throttle back this nix forum addiction thing, trying to rear it's fugly head. Tell the truth am sure I'll always and forever have much more to learn about a topic like gnu/Linux than I'll ever manage to know.

[Deb-fan]

6 cores and 6 threads ... 100% for HOURS!? Holy friggin crap man. Thinking of setting up a really stripped down install spec for compiling stuff, doesn't need X, 100hz and non-preemptive on it etc. It's awesome to see somebody showing the intiative to start tuning a distro in ways long considered generally better and appropriate for desktop gnu/Linux. Debian cured me of the distro-hop a long time ago but was d-hopping like a madman for awhile and only ever seen one distro release with a notable deviation, they had set swappiness to 0 out-of-box, imo too low and now setting such supposedly disables swap altogether. I just set it to 10 and went on with life. Still thought it was cool at the time and is cool you're doing it and taking steps with MX @Stevep.

[stevepusser]

6 cores and 6 threads ... 100% for HOURS!? Holy friggin crap man. Thinking of setting up a really stripped down install spec for compiling stuff, doesn't need X, 100hz and non-preemptive on it etc. It's awesome to see somebody showing the intiative to start tuning a distro in ways long considered generally better and appropriate for desktop gnu/Linux. Debian cured me of the distro-hop a long time ago but was d-hopping like a madman for awhile and only ever seen one distro release with a notable deviation, they had set swappiness to 0 out-of-box, imo too low and now setting such supposedly disables swap altogether. I just set it to 10 and went on with life. Still thought it was cool at the time and is cool you're doing it and taking steps with MX @Stevep.

Actually, I ignore Head-on's advice to disable SMT (hyperthreading for Intel), so it's twelve threads on six cores--quite an interesting display of 12 cpu use bars going up and down on the XFCE panel. Most of the time they are practically idle, too, especially since I have va-api video working in players and in for streaming video in a backported Chromium. Of course, there are newer mobile and desktop CPUs out there now with many more cores and threads.

I recently backported Libreoffice 6.4 a couple times, which even takes quite a bit longer than gcc, only to have the same packages show up in buster-backports a day later. Gotta pick your battles, I guess.

Anyway, the Liquorix kernel is not meant for power savings, but it does work much better than even my 1000 Hz Debian kernels for audio work, which needs low-latency, and for many games: https://forum.mxlinux.org/viewtopic.php ... 7&start=10 Debian has the realtime kernel, but that has its own drawbacks, one of which is that it's not going to work with an Nvidia proprietary driver.

I also do almost all my packaging outside of X and my own daily driver installation, in chroots, using these very cool pbuilder and sbuild systems that the Debian packagers use. They allow me to cross compile, not only for i386 on amd64, but even for non-x86 chips like armhf for Pi's, or arm64 for 64-bit ARM processors. The chroots start from a blank, innocent state for every build, and it's quick and easy to tack on extra repositories like the MX ones and a local repo I have in a folder for a build, and then to remove them. It's so much better than the clunky way we used to do packaging in virtual machines...yuck! Amd64 and i386 builds go at full speed--virtual machines (at least Virtual Box) impose quite a heavy slowdown in overhead, not to mention eat up RAM that the new methods don't.

MX 19 comes now with swappiness set to 15, which we thought was a nice figure for desktop users. Everyone should get involved with a small, practically a vanity distro, and see if it can incorporate some of your good ideas. Maybe it could get to the top of the Distrowatch click-through charts! (yes, I know that those charts don't mean much, but we don't have bots gaming them either )

About undervolting being dangerous...IDK, but it's done pretty much universally over on the Windows side with Throttlestop or other utilities among gamers and other gearheads trying to get all the performance they paid for. I haven't seen anyone mess up their hardware with it in the threads I read when trying to pick the "best bang for the buck" packaging laptop--and it turned out that I made a lucky choice. (2018 MSI GP63-8RD gaming laptop with excellent cooling system, everything pretty much works OOTB with MX/Debian once you figure out how to add the Linux EFI file to the boot options. So it's even dual booting, though I haven't started Win 10 in months)

[Deb-fan]

Hey thanks Stevep, was chomping at the bit wanting to ask you about your view of disabling hyperthreading but didn't want to make it any more "noisy" in this thread. Me and Head_on are apparently engaged in a quasi-fued at the moment, it's fairly obvious and you guys (regulars here)have likely noticed. Where do you stand on HT'ing setting for side-channel mitigation ? To me it just seems silly having a chip with HT and disabling it and gratefully now in kernel's 5.4.2 or newer disabling mitigations is apparently as complicated as adding mitigations=off to /etc/default/grub. I actually compile them out (page table isolation and retpoline)though don't think that's right and should use the grub file. This old things chip isn't even hyper-thread capable but if were, nope ... not disabling any benefits it must bring worrying about side-channel threats which I think mainly apply to shared hardware, multi-user systems, rather than desktop nixers.

For better/best use of a cores cache etc, turning off hyper-threading just all the way around in my view has to lower performance.

Don't really pay all that much attention to what Head_on has to say anymore. What he's posted here makes why plain. Oh power management and cpu-freqs ? Just default to performance, that's all need be done/said. All else is noise. That is of course horrendously out of touch with reality but whatever. Oh the archwiki has a very strong warning about undervolt, nope need not discuss it further, noise, noise. I know you/Stevep have been using it with obvious success for a long time, Wiz10k with the know-how and experience gained from overclocking, no doubt that will easily translate into undervolt benefits and guessing CwF could do such in his sleep. Though no, no, no ... archwiki says, I think this is all there is to this thing, noise to signal fellows. I know what I don't know, if any of the other people in this thread want to share how I and others can make a @2.6ghz proc, run like a @3ghz. My best attitude is to be grateful, shut up and listen. Learning that kind of gain is possible for a reasonable amount of effort is VERY significant to me and I thank you for sharing info on it. Same for anything you/Steve have to say about the topic of compiling, obvious you really know your stuff and my understanding of the topic is pathetic.

The guy behind the Liquorix kernel has no doubt forgotten more about kernel tweaking and config'ing than I've managed to learn and again, when comes to Debian, clear they aren't specifically focused on desktop gnu/nix users, they're trying to do the best for as wide a range as they can out-of-box and clearly expecting users to change things to best meet our needs. Again ... really cool of you to do such tuning in a distro meant for desktop nixers, no doubt one of the reasons for MX's growing popularity too. Need to leave off on the stupid fued, waste of time and energy but it's been building for a long time, across a bunch of gnu/nix forums. It's not that serious and more funny than anything but newer users put more stock in something like post count, mod status etc. Seeing them FUDerized by someone who many times doesn't know what they're talking about really irritates me. Nixers may not take any interest in really cool tuning areas of nix, cause they've been told it's risky, bad practice or whatever. No nixer, even a generally competent one has the right to do that kind of thing to others imo anyway. No, no, no ... don't do that, don't even discuss it, it's bad. Yeah ok, been doing it for years and works great. Thanks for telling me it's impossible and soooo risky. Ah forget it but still wanted to say something.

Also +1 on opting for swappiness 15, considering how the kernel uses vm for file caching. Do believe 10 is too low considering avg system specs nowadays anyway. It's just really cool seeing people like you commiting to tuning for desktop.

[Deb-fan]

Dratz, where's captain obvious when you need him?! Guess it's kind of obvious where you stand Steve, you haven't disabled HT'ing. All these folks saying ahhhhh, disabling them is no biggie in terms of performance. Yeppers with Intel being one of the main contributors, supporters of the Linux kernel and most popular/common CPUs in the world am sure the hyperthreading technology used in their chips receives very little attention from kernel devs at kernel.org. Just go ahead and turn all those pesky threads off, bah no biggie or real difference. Don't know why anyone bothered including these things anyway or paying more for em either? Don't do much of anything useful. Errrr ok ... that makes perfect sense.

Oops, guess with as much computing muscle as systems tend to come w now desktop nixer's just don't really notice and that a tiny minority will ever bother learning to tune for whatever potential all those threads could bring. The junk such as core-pinning or affinity etc. Though clear a minority seems to care what's possible with stuff like undervolting or using a kernel that's config'ed for desktop nix either. Puters come with so much excess muscle people mostly just don't care. I really do and it's awesome folks like Stevep do as well. As avg nixer's aren't going to bother learning these things for themselves. Therefore would never experience the benefits if people like Stevep don't go that extra mile and tune these things for desktop users.

[wizard10000]

bump.

Running about a 90mv undervolt now; I found an intel-undervolt-gui appimage and started playing with that. My i7-4800MQ didn't like iuvolt at all, refusing to write to CPU registers.

I compiled and checkinstalled a current copy of intel-undervolt and it works fine. AMD64 only, but I'd be happy to share via gdrive and steve or anybody else can host it if they would like

Only compile option was --enable-systemd and is disabled on install; you need to edit /etc/intel-undervolt.conf to enable it and if you want the thing to start at boot you have to enable and optionally start intel-undervolt.service

Use the appimage gooey to play around and when you find the sweet spot you plug those numbers into /etc/intel-undervolt.conf

disclaimer: this should only work on 3d-gen Intel Core processors and later, intel_pstate is required.

Anyway, I installed intel-undervolt-gui appimage. The appimage is kinda cool - it installs in /opt and you can just execute the thing as root. Interesting tool - you can get or set voltages with a gooey interface. You can play and find out what works for you - I would strongly recommend installing 'stress' and work your cpu a bunch before you declare an undervolt stable; mine remains stable with a 90mv undervolt, has passed 30 sec, 8 core stress tests like this -

Code: Select all

#   stress --cpu 8 -v --timeout 30s

I personally would stress test a processor for like 15m before I'd declare it stable and am about to do that right now

If you overdo it your machine will lock up and it'll take a hard restart to get going again - don't play with this with data open that you wouldn't care to lose

Oh, yeah - linkage: https://drive.google.com/open?id=1AZPL5 ... UMSm6PjPHv

edit: posting during 15m stress test. 8 cores at 100% usage, temp is 96C and cores are running at 3.4GHz

edit v2.0: 10 minutes into a 15-minute test, All 8 cores are running at 3.3GGHz, 100% cpu usage; temp is still 96C - at stock voltage with this laptop (Dell Precision M4800) I can bump the CPU's thermal limiter maxing out *one* core.

Thanks to steve - that was fun

okay, now i'm really gonna quit editing this message

I ended up at a -89.84mv undervolt, stress test passed.

[CwF]

MX 19 comes now with swappiness set to 15

Also +1 on opting for swappiness 15, considering how the kernel uses vm for file caching

I'd strongly recommend incorporating zram-tools for modern processors. By default it will set up 256MB worth of ram divided into a chunk per core. Useful, and that is sized for smaller mem machines. On a larger scale I run 16x128MB swap with a 4.2GB swap partition that never gets hit. I turn up swappinees to 20 to help use it. At the moment I have 92.5MB in zram and 0 swap with a 26.2GB load on 64GB box up for a few weeks, testing this among other details. There are no browsers on my hypervisors like that one. On a OS with a browser it will be much more active and helpful. Get those 80 tabs open and leave some alone for awhile, then close them without a refresh and watch a few megabytes come right out of that zram. It works very well.

temp is 96C

wow. Mine (desktops) are built semi passive with high thermal mass and it could take a half hour to reach 96C.
see if it's tripped

Code: Select all

cat /sys/devices/system/cpu/cpu0/thermal_throttle/package_throttle_count

[Deb-fan]

So you were able to get clock gains Wiz10k, by how much and do you feel comfortable enough with the arrangement to keep using it long term? With this old chip doesn't even feel it's worth bothering with but the prospect of a 10% or more clock gain is something I'm going to definitely keep in mind going forward. That's a why not, no brainier situation.

Yep ... am sure that's the mindset of grossly ignorant folks in general. Want more speed, buy a faster chip, want best performance, just set things up so the clock is full bore, all times, some poss sec threat, I don't ever bother getting to the point of understanding which could exploit core cache, just disable hyperthreading, don't bother learning how kernel configs impact chip and app performance. A person which actually bothers taking an interest in these things, can take a lower spec chip and get more out of it all day long. Does take having an active interest though or again a distro dev-maintainer like @Stevep who does and does it for folks.

[stevepusser]

disclaimer: this should only work on 3d-gen Intel Core processors and later, intel_pstate is required.

I didn't find pstate to be a requirement when I tested booting various kernels with it disabled--Secure Boot must be disabled, though.

I found that for my Intel Skylake i5-6200u laptop, I also had to first run i7z before iuvolt was able to write the new values to the msr registers. Maybe it unlocks them just by reading the values or something, but anyway, the little scriptlet I have to autostart iuvolt now runs i7z first, then sleeps a couple seconds before running iuvolt. The lowest stable values on that laptop are also about -90, so the inputs are "-90 -85 -90" (first and last must be equal, the middle one undervolts the GPU), while the settings for the MSI GP63 i7-8750H laptop are "-143.6 -100 -143.6", from Windows user's Throttlestop settings.

Thanks for the gooey Appimage settings and the binary! Maybe I can package intel-undervolt for MX...seems pretty straightforward.

More recent and powerful chips like my i7 can run into thermal throttling issues constantly, but I never see that happen on the power-sipping 15 W TDP i5-6200u. But undervolting still allows either to use less power, so run cooler with longer battery life.