Intel GPUs Gain 20% Performance by Disabling Security Mitigations

[erek]

"Intel's confidence in disabling these checks stems from the fact that modern Linux kernels already address Spectre vulnerabilities comprehensively at the operating system level. To keep users informed, the Compute Runtime build will emit a warning if it detects a kernel lacking the necessary patches, ensuring transparency about any residual risk. Canonical's Ubuntu team has partnered with Intel to introduce this enhancement in its upcoming 25.10 release. But make no mistake, this is Intel's initiative: the company is driving the performance improvements, publishing unmitigated binaries upstream, and coordinating with distribution partners to make the change broadly available. Security teams at Intel have analyzed the potential attack surface and concluded that the performance gains far outweigh the minimal risk, especially given that Intel's own builds have been running unmitigated without incident."

Source: https://www.techpowerup.com/338254/intel-gpus-gain-20-performance-by-disabling-security-mitigations

 

[Lakados]

Spectre and Meltdown are the kind of vulnerabilities that by the time the attacker is in a position to exploit them, they already have the ability to do far worse.

If someone has cracked your system far enough down to execute these, and that’s all they do, you are absurdly lucky, and your attacker is an idiot.

 

[DukenukemX]

This is probably a better source to this info. You can fix this by just adding i915.mitigations=off to /etc/default/grub or /etc/sdboot-manage.conf if you're using systemd like myself. The problem Intel has had is that their GPU performance in Linux is generally ~10% worse than Windows. I doubt this will fix that, but who knows?

https://www.phoronix.com/news/Disable-Intel-Gfx-Security-20p

 

[MrGuvernment]

Spectre and Meltdown are the kind of vulnerabilities that by the time the attacker is in a position to exploit them, they already have the ability to do far worse.

If someone has cracked your system far enough down to execute these, and that’s all they do, you are absurdly lucky, and your attacker is an idiot.

This, the place this came into consideration was cloud platforms and shared resources (VPS hosts et cetera), where an attacker could fire up a VM or system on a provider and start trying to collect / dump things to then compromise via said exploit, but even that was like a 1-in-a-million chance to actually get anything useful.

 

[DanNeely]

This is probably a better source to this info. You can fix this by just adding i915.mitigations=off to /etc/default/grub or /etc/sdboot-manage.conf if you're using systemd like myself. The problem Intel has had is that their GPU performance in Linux is generally ~10% worse than Windows. I doubt this will fix that, but who knows?

https://www.phoronix.com/news/Disable-Intel-Gfx-Security-20p

Phoronix may be a more technical source, but in this case I'm going to have to give the not to TPU. The mitigations Intel is removing from the driver being redundant with ones in the kernel is the key detail that changes the story from insane to reasonable.

 

[Lakados]

This, the place this came into consideration was cloud platforms and shared resources (VPS hosts et cetera), where an attacker could fire up a VM or system on a provider and start trying to collect / dump things to then compromise via said exploit, but even that was like a 1-in-a-million chance to actually get anything useful.

And even then, it relied on the host system not having the necessary protections in place which already exist at a software level via other patches.
So it required compound errors to be viable in the wild.

 

[leSLIe]

?
Does this work in any intel cpu?
And how to disable this stuff to gain more HP?

 

[DukenukemX]

?
Does this work in any intel cpu?
And how to disable this stuff to gain more HP?

Works on any Intel GPU. Don't think the CPU matters. You see how to do it with my post here. The correct way to do this is to install a PPA and install a specific kernel, as mentioned in the Phoronix article. Or do my method and then run sudo update-grub, again if you're using grub. Think with systemd you just update the kernel afterwards.

 

[Mazzspeed]

I disabled CPU security mitigations under KDE Neon 6.4 quite some time back, kept the 'ol 8700k running at it's peak for a little while longer. Open grub and add the line:

GRUB_CMDLINE_LINUX="mitigations=off"

 

[michalrz]

lscpu

Spoiler

Architecture:             x86_64
  CPU op-mode(s):         32-bit, 64-bit
  Address sizes:          43 bits physical, 48 bits virtual
  Byte Order:             Little Endian
CPU(s):                   12
  On-line CPU(s) list:    0-11
Vendor ID:                AuthenticAMD
  Model name:             AMD Ryzen 5 3600 6-Core Processor
    CPU family:           23
    Model:                113
    Thread(s) per core:   2
    Core(s) per socket:   6
    Socket(s):            1
    Stepping:             0
    Frequency boost:      enabled
    CPU max MHz:          3600,0000
    CPU min MHz:          2200,0000
    BogoMIPS:             7186.65
    Flags:                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_
                          good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legac
                          y svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_
                          pstate ssbd mba ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 cqm_llc cqm_occup_llc cqm_
                          mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthres
                          hold avic v_vmsave_vmload vgif v_spec_ctrl umip rdpid overflow_recov succor smca sme sev sev_es
Virtualization features:  
  Virtualization:         AMD-V
Caches (sum of all):      
  L1d:                    192 KiB (6 instances)
  L1i:                    192 KiB (6 instances)
  L2:                     3 MiB (6 instances)
  L3:                     32 MiB (2 instances)
NUMA:                      
  NUMA node(s):           1
  NUMA node0 CPU(s):      0-11
Vulnerabilities:          
  Gather data sampling:   Not affected
  Itlb multihit:          Not affected
  L1tf:                   Not affected
  Mds:                    Not affected
  Meltdown:               Not affected
  Mmio stale data:        Not affected
  Reg file data sampling: Not affected
  Retbleed:               Mitigation; untrained return thunk; SMT enabled with STIBP protection
  Spec rstack overflow:   Mitigation; safe RET
  Spec store bypass:      Mitigation; Speculative Store Bypass disabled via prctl and seccomp
  Spectre v1:             Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:             Mitigation; Retpolines; IBPB conditional; STIBP always-on; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected
  Srbds:                  Not affected
  Tsx async abort:        Not affected

 

[MrGuvernment]

And even then, it relied on the host system not having the necessary protections in place which already exist at a software level via other patches.
So it required compound errors to be viable in the wild.

Exactly, but you still had companies getting teams to drop everything and patch everything now for their on-prem systems because "Oh Noes bad exploit"

 

[ChadD]

Exactly, but you still had companies getting teams to drop everything and patch everything now for their on-prem systems because "Oh Noes bad exploit"

To be fair for a lot of industries. They should absolutely NOT be turning off mitigations. People confuse the "no in the wild viruses" known to use... with side channel attacks are ineffective. They are not so effective that malware your grandpa downloads is going to exist. However they are still potentially very effective against valuable targets. Not all the side channel attacks require physical access. Which is the other "don't worry" just don't plug a USB stick in argument. I have zero doubt real world exploits have used side channel attacks. They are just not the types of wide spread attacks you hear about in news reports. If your a home user ya less worry, if your a larger business, financial, medical, gov. I wouldn't turn any mitigations off. Your personal gaming machine ok mitigations=off... the business server ah no mitigations remain on.

Intel in this is not suggesting companies turn of CPU mitigations, this Ubuntu thing is about adding a GPU mitigation off flag. This is directly related to GPU security mitigations. To be honest I have no idea how sever the GPU vulnerabilities are. I will say this though. Intel has taken 20% in performance hits to their GPU compute performance (this isn't talking about igpu stuff though it may also be effected) we are talking about the compute racks of battlemage type stuff. The stuff Intel is betting the damn company on. I'm not going to lie if I'm in charge of purchasing R&D systems to possibly move away from Nvidia, knowing Intel has taken a 20% performance hit via mitigations is going to turn me right off before even entertaining conversations with them. Compound that with most purchasers already having dealt with CPU mitigation performance hits the last 5 years. I mean how much worse could security holes get for Intel GPU compute stuff? Its barely used right now what happens when more people are using it, more researchers are looking into it? Intel seems to have a habit of iffy security design.

I guess I'm saying Intel probably should have been more quite about this plan to include a NEO_DISABLE_MITIGATIONS. A GPU version of mitigations=off. IMO it is terrible PR for Intel that after getting clobbered on CPU security for years now, they are also pointing out that their GPUs are also designed with security issues baked in.

 

[ChadD]

lscpu

Spoiler

Architecture:             x86_64
  CPU op-mode(s):         32-bit, 64-bit
  Address sizes:          43 bits physical, 48 bits virtual
  Byte Order:             Little Endian
CPU(s):                   12
  On-line CPU(s) list:    0-11
Vendor ID:                AuthenticAMD
  Model name:             AMD Ryzen 5 3600 6-Core Processor
    CPU family:           23
    Model:                113
    Thread(s) per core:   2
    Core(s) per socket:   6
    Socket(s):            1
    Stepping:             0
    Frequency boost:      enabled
    CPU max MHz:          3600,0000
    CPU min MHz:          2200,0000
    BogoMIPS:             7186.65
    Flags:                fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_
                          good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legac
                          y svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_
                          pstate ssbd mba ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 cqm_llc cqm_occup_llc cqm_
                          mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthres
                          hold avic v_vmsave_vmload vgif v_spec_ctrl umip rdpid overflow_recov succor smca sme sev sev_es
Virtualization features:
  Virtualization:         AMD-V
Caches (sum of all):    
  L1d:                    192 KiB (6 instances)
  L1i:                    192 KiB (6 instances)
  L2:                     3 MiB (6 instances)
  L3:                     32 MiB (2 instances)
NUMA:                    
  NUMA node(s):           1
  NUMA node0 CPU(s):      0-11
Vulnerabilities:        
  Gather data sampling:   Not affected
  Itlb multihit:          Not affected
  L1tf:                   Not affected
  Mds:                    Not affected
  Meltdown:               Not affected
  Mmio stale data:        Not affected
  Reg file data sampling: Not affected
  Retbleed:               Mitigation; untrained return thunk; SMT enabled with STIBP protection
  Spec rstack overflow:   Mitigation; safe RET
  Spec store bypass:      Mitigation; Speculative Store Bypass disabled via prctl and seccomp
  Spectre v1:             Mitigation; usercopy/swapgs barriers and __user pointer sanitization
  Spectre v2:             Mitigation; Retpolines; IBPB conditional; STIBP always-on; RSB filling; PBRSB-eIBRS Not affected; BHI Not affected
  Srbds:                  Not affected
  Tsx async abort:        Not affected

If your system is only used by you, you are not doing any production work and such. (I assume your not). You might want to consider going mitigations=off.
I don't consider the potential exposure risk to be very high... heavy performance hit though in some workloads.
https://www.phoronix.com/review/amd-3950x-retbleed
Redbleed will cost Zen2 20% or so in performance in general. If you really have a system that could be a potential target... just upgrade to a Zen3 which isn't vulnerable.

 

[michalrz]

If your system is only used by you, you are not doing any production work and such. (I assume your not). You might want to consider going mitigations=off.
I don't consider the potential exposure risk to be very high... heavy performance hit though in some workloads.
https://www.phoronix.com/review/amd-3950x-retbleed

Yeah man, only me, the system sits at home and no one messes with it.
I multitask and such, might go into video editing, but also use it for work.
But, because I was never really concerned with its performance (good enough for me), I left them on. But I do plan to eventually try disabling the mitigations, don't know yet. Just wanted to share the command, very useful.
Thanks for the tip!

 

[ChadD]

Yeah man, only me, the system sits at home and no one messes with it.
I multitask and such, might go into video editing, but also use it for work.
But, because I was never really concerned with its performance (good enough for me), I left them on. But I do plan to eventually try disabling the mitigations, don't know yet. Just wanted to share the command, very useful.
Thanks for the tip!

Its a pretty simple to do. Thankfully Zen2 doesn't have any crazy mitigations you should worry about leaving on. If you had a older Intel chip I might say its smarter to selectively turn a few things off and leave others on. With Zen2 just turning them all off is fine. imo Just find your boot loaders config file... and add mitigations=off to the launch commands. (where you will see other boot arguments like quite and splash) Double check with your distro, and or boot loader config. With every Linux boot loader it should be as simple as opening the txt config file and just adding that line.

If you do any gaming with Wine/Proton or run any software via wine really. Also turn off split lock "mitigation". Split locks are a programming no no... basically for atomic operations (things that run without interruption like a timer) is written in a way where it needs to access more then one set of cached data. This can force the CPU and or scheduler to implement a global bus lock that slows down systems. Some one in Linux land got annoyed to the point where they suggested adding a "mitigation" that basically purposely breaks software doing this. Its not a security issue in anyway... its just poor code hygiene that annoys people. lol Anyway the entire point of the "mitigation" is to annoy people using software that uses split locks so that will pressure developers to fix their code. Unfortunately if your emulating a windows game, or some older piece of windows software that is guilty of this type of thing... there isn't much your going to do to get them to fix their ass code. So just turn the mitigation off so that old game you want to play doesn't run even worse on purpose.
kernel.split_lock_mitigate=0

 

[DukenukemX]

I disabled CPU security mitigations under KDE Neon 6.4 quite some time back, kept the 'ol 8700k running at it's peak for a little while longer. Open grub and add the line:

GRUB_CMDLINE_LINUX="mitigations=off"

You'll have to add i915.mitigations=off to get the 20% gain for Intel GPU's.

 

[michalrz]

Its a pretty simple to do. Thankfully Zen2 doesn't have any crazy mitigations you should worry about leaving on. If you had a older Intel chip I might say its smarter to selectively turn a few things off and leave others on. With Zen2 just turning them all off is fine. imo Just find your boot loaders config file... and add mitigations=off to the launch commands. (where you will see other boot arguments like quite and splash) Double check with your distro, and or boot loader config. With every Linux boot loader it should be as simple as opening the txt config file and just adding that line.

If you do any gaming with Wine/Proton or run any software via wine really. Also turn off split lock "mitigation". Split locks are a programming no no... basically for atomic operations (things that run without interruption like a timer) is written in a way where it needs to access more then one set of cached data. This can force the CPU and or scheduler to implement a global bus lock that slows down systems. Some one in Linux land got annoyed to the point where they suggested adding a "mitigation" that basically purposely breaks software doing this. Its not a security issue in anyway... its just poor code hygiene that annoys people. lol Anyway the entire point of the "mitigation" is to annoy people using software that uses split locks so that will pressure developers to fix their code. Unfortunately if your emulating a windows game, or some older piece of windows software that is guilty of this type of thing... there isn't much your going to do to get them to fix their ass code. So just turn the mitigation off so that old game you want to play doesn't run even worse on purpose.
kernel.split_lock_mitigate=0

Any chance I'll get some extra oomph on my qemu-based Win10 Virtual machine? I use that for Word, can't risk have it crash even if I got it to work on Wine (I think the 32-bit one runs).
Asking because the VM is choppy, always has been, despite several tweaks (selecting other VGA modes, adding/removing RAM, allocating the RAM beforehand, pre-allocating a bunch of cores, SSD...)

 

[ChadD]

Honestly, it makes sense that Intel feels confident disabling those Spectre checks since Linux kernels have gotten pretty solid at handling those vulnerabilities on their own. The warning system in the runtime build is a nice touch to keep users aware if their kernel isn’t fully patched. It’s cool to see Intel pushing this and working closely with Ubuntu to roll it out smoothly. Performance boosts are always welcome, and if Intel’s security folks are sure the risk is low, especially since their unmitigated builds have been stable, then it sounds like a reasonable trade-off.

This isn't about CPU mitigations though.
This article is sort of poorly written.
This new NEO_DISABLE_MITIGATIONS flag is to disable GPU Compute Mitigations. Intel GPUs like ARC and Battlemage take about a 20% performance hit from Linux GPU compute security mitigations. This has nothing actually to do with Specter or Meltdown or any other CPU issues.

The part of the article that actually matters... "disabling these driver-level mitigations can significantly speed up shader compilation, AI-driven upscaling routines, and physics simulations that rely on GPU compute."
The part that is super confusing is this line... "The company has long incorporated security mitigations into its open-source Compute Runtime to protect against vulnerabilities like Spectre, but these safeguards have carried a hidden cost."

The phoronix article Duke posted in the thread, better details what this is about.
https://www.phoronix.com/news/Disable-Intel-Gfx-Security-20p
"While not talked about as much as the Intel CPU security mitigations, Intel graphics security mitigations have added up over time that if disabling Intel graphics security mitigations for their GPU compute stack for OpenCL and Level Zero can yield a 20% performance boost."

The real take away most people should get from this news.... is that Intel can't design GPUs without baking in vulnerabilities as well. lol

 

[ChadD]

Any chance I'll get some extra oomph on my qemu-based Win10 Virtual machine? I use that for Word, can't risk have it crash even if I got it to work on Wine (I think the 32-bit one runs).
Asking because the VM is choppy, always has been, despite several tweaks (selecting other VGA modes, adding/removing RAM, allocating the RAM beforehand, pre-allocating a bunch of cores, SSD...)

From mitigations off ya probably some. Split locks? maybe probably not. I don't think microsoft word would be guilty of using split locks, never tested that though. lol
For split locks anyway the software that is the worst offending stuff generally tends to be games, often indy or less then great game developers anyway. Some older MMOs, as an example if you play Star Trek online you'll want to disable split lock mitigation. Its a 15 year old game where the engine devs are long gone and over the years different devs have added different things. So you might open a list to select cards for a card game that was tacked on when the game was 7 years old and your 165fps will drop to 70fps because that screen is open, and jump back when its closed. That type of stupidity... were a dev has atomic operations working within existing atomic operations using data from that cache and pulling and caching data from some other database. Just poorly made sloppy code. Old MMOs or old games with mods and such will be the worst offending stuff people would run into. As I understand it split locks seep into code more that way then a coder actually doing it on purpose.

 

[michalrz]

From mitigations off ya probably some. Split locks? maybe probably not. I don't think microsoft word would be guilty of using split locks, never tested that though. lol
For split locks anyway the software that is the worst offending stuff generally tends to be games, often indy or less then great game developers anyway. Some older MMOs, as an example if you play Star Trek online you'll want to disable split lock mitigation. Its a 15 year old game where the engine devs are long gone and over the years different devs have added different things. So you might open a list to select cards for a card game that was tacked on when the game was 7 years old and your 165fps will drop to 70fps because that screen is open, and jump back when its closed. That type of stupidity... were a dev has atomic operations working within existing atomic operations using data from that cache and pulling and caching data from some other database. Just poorly made sloppy code. Old MMOs or old games with mods and such will be the worst offending stuff people would run into.

I have one game on Steam. That game is Project Zomboid. Ever heard of it?
Yeah... But it's a gem of an indie game. And, indeed, it's buggy as hell, so you sold me on the idea of trying out going without mitigations.
I just didn't care before about that game's performance in particular, because I'm stuck on a GT730 for now (so that was a big offender). But, hey, I'll let you know if I see any benefits.

 

[ChadD]

I have one game on Steam. That game is Project Zomboid. Ever heard of it?
Yeah... But it's a gem of an indie game. And, indeed, it's buggy as hell, so you sold me on the idea of trying out going without mitigations.
I just didn't care before about that game's performance in particular, because I'm stuck on a GT730 for now (so that was a big offender). But, hey, I'll let you know if I see any benefits.

Ya I haven't heard of it. Looking though I see its written in Java... ya could potentially have issues with split locks.
Having said that...
https://www.protondb.com/app/108600 I mean its rated platinum on ProtonDB. Probably not using splitlocks. But I would disable that mitigation anyway. I don't consider making programs run bad on purpose to be a mitigation. lol

You can test split lock issues with that game without having to touch your boot config if you want. Kernel mitigations mostly need to be enabled via boot. Splitlock though you can enable with a sysctl call. When you reboot it will be back on though. If you want to test before changing it though.

sudo sysctl kernel.split_lock_mitigate=0

 

[Lakados]

Exactly, but you still had companies getting teams to drop everything and patch everything now for their on-prem systems because "Oh Noes bad exploit"

In all fairness, if those companies were already doing some sketchy software things to "maximize" their hardware investment, and they were over provisioning their hardware, then they did have a potential issue, and it came out while there were many high profile data leaks.
Nobody wanted to be the source of the next big leak, insurance companies were rejecting more while government watchdogs were looking for somebody to throw the book at to make it look like they were protecting consumers.
So it came out at the perfect time for CEO's and upper management to panic over.

And in the end, it amounted to nothing, and didn't result in any fewer data leaks, because ultimately attacking the hardware is complex, time consuming, unreliable, and expensive. But attacking the people is cheap, easy, and automated, the flesh is weak.

 

[michalrz]

Ya I haven't heard of it. Looking though I see its written in Java... ya could potentially have issues with split locks.
Having said that...
https://www.protondb.com/app/108600 I mean its rated platinum on ProtonDB. Probably not using splitlocks. But I would disable that mitigation anyway. I don't consider making programs run bad on purpose to be a mitigation. lol

You can test split lock issues with that game without having to touch your boot config if you want. Kernel mitigations mostly need to be enabled via boot. Splitlock though you can enable with a sysctl call. When you reboot it will be back on though. If you want to test before changing it though.

sudo sysctl kernel.split_lock_mitigate=0

I did not have the split_lock_mitigation in the /proc/sys/kernel folder, and it wasn't mentioned in mitigations.

However, I did update and launch the system with the grub line.
Might be totally placebo, but Firefox and Word start near instantly in the Win10 VM, and my game seems to be working without those slight stutters I sometimes saw.
Again, placebo is a helluva drug, so I'll keep using the system like that.
If I find some time, I will run sysbench with and without the mitigations a few times (A/B/A/B) after I de-dust my machine (to rule out thermal reductions of Turbo).

 

[Haswellbeast]

See, maybe I should try compiling my own custom kernel again. Last time I did that, I was up until 3am and never got past kernel panic on boot

 

[michalrz]

See, maybe I should try compiling my own custom kernel again. Last time I did that, I was up until 3am and never got past kernel panic on boot

I used to be really into that back in the Linux 2.6 days (so, like, 2006?). I mostly wanted to set the architecture from the default i686 to k8.
Did try some other tweaks as well, but it got old whenever a graphics update got published and it required me to re-compile the nVidia driver as well.
Nowadays, because I need it all to work always (so, full drive images, UPS, no OC) for work, I had to cut it out.
...but it IS fun

 

[Haswellbeast]

I used to be really into that back in the Linux 2.6 days (so, like, 2006?). I mostly wanted to set the architecture from the default i686 to k8.
Did try some other tweaks as well, but it got old whenever a graphics update got published and it required me to re-compile the nVidia driver as well.
Nowadays, because I need it all to work always (so, full drive images, UPS, no OC) for work, I had to cut it out.
...but it IS fun

I've heard the best thing (besides disabling mitigations and the like) is trying out schedulers, as I have heard that the default one is very servery background task kind of thing.

 

[michalrz]

I've heard the best thing (besides disabling mitigations and the like) is trying out schedulers, as I have heard that the default one is very servery background task kind of thing.

Hehe, yup. Some don't even use Turbo.

I remember, the only time I ever touched the kernel source files, was finding the one responsible for k8 (AMD64) cool'n'quiet and basically forcing it to operate on the lowest frequency by editing a constant in the code.
After recompiling the whole shebang, I had a special scheduler that I'd call upon if I ever needed to make sure it was always running low-power.
I remember trying experimental features (back then experimental) like EXT4 (and corrupting my filesystem). Tickless kernel, of throwing out drivers I won't ever need. We had this running contest with my other nerd friend about who can make the smallest kernel binary, so that it fits in the CPU's cache if need be.
Please, do share any other fun stuff you discovered on your travels.

I'm pretty sure my system is snappier without the mitigations. But I need to bench it with and without a few times.

 

[michalrz]

Bumping this mainly to let ChadD know (and for the benefit of others).
Disabling the mitigations on my Zen 2 (3600) made the QEMU/KVM Windows 10 Virtual Machine operate way snappier. It's no longer a chore to use it (for some Word documents).

 

[ChadD]

Bumping this mainly to let ChadD know (and for the benefit of others).
Disabling the mitigations on my Zen 2 (3600) made the QEMU/KVM Windows 10 Virtual Machine operate way snappier. It's no longer a chore to use it (for some Word documents).

The mitigations for all the side channel stuff really hit VMs hard. For servers running virtual systems for many customers the mitigations are basically required. (all the commercial providers use newer CPUs that don't have the same issues). It was important to have them mitigated though for any providers that hadn't migrated to newer systems yet. If you still had Zen2 based Epyc servers or whatnot. Running your own local VM though? Ya nothing to fear turning them off right.

 

[michalrz]

The mitigations for all the side channel stuff really hit VMs hard. For servers running virtual systems for many customers the mitigations are basically required. (all the commercial providers use newer CPUs that don't have the same issues). It was important to have them mitigated though for any providers that hadn't migrated to newer systems yet. If you still had Zen2 based Epyc servers or whatnot. Running your own local VM though? Ya nothing to fear turning them off right.

Yeah, nah, my VM provides nothing to outside. It's a Word machine, rarely booted up, runs maybe for a few days per month. The sluggishness was affecting my workflow hard. Now it's just easier on the eyes (no screen tearing on refreshing windows,etc.).

 

[OKC Yeakey Trentadue]

Intel gains 20% profits by eliminating immigration mitigations.