OpenSUSE's Spectre Mitigation Approach Is One Of The Reasons For Its Slower Performance

[LinAGKar]

And no one who spent real money and wanted better performance would be stupid enough to stick with the defaults.

Show me a guide on how to make it fast then. For example, how do you switch to retpolines?

[andyprough]

Show me a guide on how to make it fast then. For example, how do you switch to retpolines?

Did you happen to read the article that you are commenting on right now? I believe that all you are asking is laid out there for you, with links and command line parameters and everything. This is not some secret, mystical knowledge that is being hidden from you.

[LinAGKar]

Did you happen to read the article that you are commenting on right now? I believe that all you are asking is laid out there for you, with links and command line parameters and everything. This is not some secret, mystical knowledge that is being hidden from you.

I presume you're supposed to add spectre_v2=retpoline,generic to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, and that will disable ibrs, which is not clear from the article. Anyway, I just checked my Tumbleweed system, and it already seems to be using retpolines:

> cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling
> cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.0.7-1-default root=UUID=9dfdcf90-5515-4e84-b6f4-b24d9851e4bb resume=/dev/sdb5 splash=silent quiet showopts

Also, there is more things that would be in such a guide.

[andyprough]

I presume you're supposed to add spectre_v2=retpoline,generic to GRUB_CMDLINE_LINUX_DEFAULT in /etc/default/grub, and that will disable ibrs, which is not clear from the article. Anyway, I just checked my Tumbleweed system, and it already seems to be using retpolines:

> cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Full generic retpoline, IBPB: conditional, IBRS_FW, STIBP: conditional, RSB filling
> cat /proc/cmdline
BOOT_IMAGE=/boot/vmlinuz-5.0.7-1-default root=UUID=9dfdcf90-5515-4e84-b6f4-b24d9851e4bb resume=/dev/sdb5 splash=silent quiet showopts

Also, there is more things that would be in such a guide.

If I were you, I would scroll through this openSUSE devs mailing list thread, as it points out that certain CPUs are not impacted, and some are not: https://lists.opensuse.org/opensuse-.../msg00126.html

You can check whether your CPU is impacted and whether IBRS is active with the spectre-meltdown-checker.sh shell script: https://www.cyberciti.biz/faq/check-...vulnerability/

YaST has a nice Boot Loader module for adding grub command line parameters if I recall, but I don't have an openSUSE system running right now to check.

Do you know how to use the cpupower command line utility to change the openSUSE CPU governor to performance setting? If not, let me know, I have a quick writeup on how to use it. Obviously, using EXT4 instead of btrfs (where possible), and turning off (or sanely scheduling) baloo indexing in KDE are important for performance.

Here are some other performance tips that have been shared in this forum thread. I haven't had time to try them yet on a fresh install. One of the suggestions is to disable Spectre/Meltdown mitigation, but do that at your own risk:
Originally posted by mgmartin View Post
The kernels I compiled are using Mitigation: Full generic retpoline .
The other changes I made from the stock OpenSUSE kernel config to match what I typically run:
OpenSUSE Leap default value --> changed value
CONFIG_HZ_250=y --> CONFIG_HZ_1000=y
CONFIG_NO_HZ_IDLE=y --> CONFIG_NO_HZ_FULL=y
CONFIG_PREEMPT_NONE=y --> CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_SCHED_AUTOGROUP is not set --> CONFIG_SCHED_AUTOGROUP=y
With these changes, I haven't seen any perceivable performance loss running OpenSUSE as my primary desktop and on some servers.


Originally posted by ms178 View Post
I also run a Laptop with openSUSE Tumbleweed, a custom Kernel config and with the Spectre/Meltdown mitigations disabled. I'd also turn off debug symbols and change the CPU governor to performance and use blk-mq as I/O scheduler.


Originally posted by mgmartin View Post
Good points I missed to call out! -- I use blk-mq (standard now with a 5.0.x kernel), set schedutil as the governor, and set CONFIG_DEBUG_KERNEL=n .

[LinAGKar]

Thanks, that's more useful.

If I were you, I would scroll through this openSUSE devs mailing list thread, as it points out that certain CPUs are not impacted, and some are not: https://lists.opensuse.org/opensuse-.../msg00126.html

You can check whether your CPU is impacted and whether IBRS is active with the spectre-meltdown-checker.sh shell script: https://www.cyberciti.biz/faq/check-...vulnerability/

Sorry, I saw that they only considered it to be insecure on skylake+, but I assumed they used the same settings on all CPUs.

Do you know how to use the cpupower command line utility to change the openSUSE CPU governor to performance setting? If not, let me know, I have a quick writeup on how to use it.

Yeah, I learned that from the Feral launcher. Well, there they wrote about writing to /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor, but does the same thing.

Obviously, using EXT4 instead of btrfs (where possible),...

I have switched to EXT4 for /home, but I'll remain on btrfs on / for the snapshots. That's something I feel is worth the performance tradeoff.

...and turning off (or sanely scheduling) baloo indexing in KDE are important for performance.

That I have done.

Here are some other performance tips that have been shared in this forum thread. I haven't had time to try them yet on a fresh install. One of the suggestions is to disable Spectre/Meltdown mitigation, but do that at your own risk:

That all seems to require compiling a custom kernel, apart from switching I/O scheduler. Not something I suspect most people would bother with.

[andyprough]

Thanks, that's more useful....
That all seems to require compiling a custom kernel, apart from switching I/O scheduler. Not something I suspect most people would bother with.

I've compiled my own kernels for a couple of years. Just compiling on my own machine seems to give better performance than using one from a distro repository. With the speed and power of modern CPU's, it seems like it should become more common. I'm interested in trying the different I/O scheduler next time I install openSUSE.

[g3wcm2V8uqwR]

...
Gentoo.......the god, meta based distro, limitless flexbility and possibilities, nothing gets in your way
...
Archlinux...among things, rolling distro, easy to install and easy to stay up to date, however user has no choice of how software was compiled, hence he/she goes back to gentoo

You only get back to Gentoo if you don't mind running some packages' ./configure as root while building it. (ie. "you can't stop the compiler from being called during phases that run as root." - "some phases (such as pkg_setup) still run as root"). But do let me know if you figure out how to avoid that.

Gentoo is basically Arch with compile flags, it's not particularly different. If you know how to install/use Arch you can learn Gentoo in an evening. And I'm not kidding.

To my knowledge, no unpacking/configuring/compiling happens as root on ArchLinux(at least not when using makepkg), only fully-finalized-package installing. Otherwise I'd be choosing Gentoo also!

[starshipeleven]

To my knowledge, no unpacking/configuring/compiling happens as root on ArchLinux(at least not when using makepkg), only fully-finalized-package installing. Otherwise I'd be choosing Gentoo also!

I quite frankly have no idea, I was talking from a user skill standpoint.

Running configure as root or not has no functional difference. (Yes it is a bad thing, but works the same).

[skeevy420]

To my knowledge, no unpacking/configuring/compiling happens as root on ArchLinux(at least not when using makepkg), only fully-finalized-package installing. Otherwise I'd be choosing Gentoo also!

That's the way it works on Arch IF makepkg is used. Everything can be done as root if you do it manually. Arch won't save you there.

On Gentoo where it can run as root, you should do it all within a chroot and then install that package to the main system (which is what Arch recommends doing as well). That's also what Gentoo users have recommended to me when asked because I plan on making the switch eventually...

The actual reasons Arch doesn't allow makepkg to run as root are because most end-users are fucktards and don't build packages in clean chroots due to using AUR helpers (myself included), because it's easier to hack a package to compile with root, because maliciously written packages can screw you if you run them as root, etc.

inside a chroot it's fine to run it as root, outside of one you can F yourself in the A if you don't know how to read PKGBUILDs, scripts, etc since some asshat could add an rm -rf / buried in a python script the PKGBUILD calls during the prepare() phase.

The reality is that Arch and Gentoo aren't any different in the practices that we're supposed to follow with the only practical difference being that Arch has moron filters on some of their tools because people are lazy and don't follow the recommended ways.

[skeevy420]

I've compiled my own kernels for a couple of years. Just compiling on my own machine seems to give better performance than using one from a distro repository. With the speed and power of modern CPU's, it seems like it should become more common. I'm interested in trying the different I/O scheduler next time I install openSUSE.

I've been compiling my kernels for years as well; recently discovered tk-glitch's repos and I've been using them since January. Currently using 5.0.9 with BMQ set to 0 and it works damn well on my desktop. Also one of the sweetest kernel customizing setups I've come across in a good while. AFAIK, all the Lutris Wine builds come from this repository and they're also very, very customizable.

As for IO schedulers...I use ZFS and BTRFS and have found that "none" works the best on my spinning rust in regards to desktop latency and response.