Mitigating the Performance Impact of Meltdown/Spectre Kernel Patches

The Performance Issues Introduced by The Vulnerability Mitigations Can Cripple Developmer Machines' Performance

Attila Orosz
Mitigating the Performance Impact of Meltdown/Spectre Kernel Patches
  • Social
  • 0

Meltdown and Spectre took the world (but not the industry) by surprise after the carefully guarded information leaked into the public consciousness. While the revelation was not intentional (from the industry's side anyway), the lack of action was. Of course patches had to be issued in a hurry after the world learned about just how serious the vulnerabilities are, and given the short timeframe, the first patches are just, well, patchy...

A lot has been said and written about the performance penalty resulting from these patches. After all, the offending CPU "features" were meant to enhance performance, so disabling them were expected to have an impact. While most of the reporting was basically hype, and apparently served no other purpose than distract the public's attention from some far more serious implications, some have really felt the patches coming back to bite them on the rear-parts.

Particularly those working with software development tools feel a performance decrease, as compile and build times can greatly increase with the pached kernels. Managed languages such as Java might perform even worse, so if you are working with something like Java and/or doing Android development, you might have noticed your IDE locking up, freezing or just generally underperforming.

Of course the currently available patches are the first responses to the problem, cobbled together in record time. The primary focus was mitigation, performance issues are so far seen as a side effect. Once the dust settles, we can hopefully expect better, more efficient solutions to replace the current ones, and while no software solution can counterbalance the spectacularly stupid hardware design decisions that introduced the problems in the first place, there is still hope that eventually, we end up with something workable.

Until such time, however, developers can simply re-enable their machines, by turning off the patches.

Before you proceed: Make Sure You Understand the Risks

This Ubuntu Insights article discusses the issue in some detail, with additional resources provided for further reading. Despite its use of the same PR-esque language as your average hype-aggregator would (calling the vulnerabilities "attacks", as opposed to what they really are: vulnerabilities caused by deliberately idiotic, faulty hardware design), it's worth reading.

One important conclusion of said article is that average Desktop users will experience negligible slowdowns resulting from the patches, so minimal that most would probably not even notice if their attention had not been hijacked by overhyped reporting on how bad it will all get fo us.

If you do have real-time issues, e.g. the very noticeable performance decrease, and frequent freezes of Android Studio, IntelliJ or Eclipse (and other) IDEs, and the two-three times longer build times on larger projects, etc., you still want to do everything you can to lower the risks of going "patchless".

Physically securing the machines, using strong passwords, locking properly when leaving your workstation, using the latest browsers (as the most common attack surface might be your browsers JS engine), are absolutely necessary pre-requisites of going "patchless".

You should read everything you can on the vulnerabilities, and the risks associated with disabling the patches. This article is only meant to provide a quick way to do this, but the responsibility is ultimately your own.

Disable the offending patches

Once again, if you came here because you've read an article about the performance impact of the patches and now you fear for your life because Facebook might load slower, or you're looking to enhance PC performance because some stupid game might run faster, stop reading now, uninstall your browser, turn off the PC, tear out the hard-drive, and declare yourself unfit to operate computing equipment.

This cannot be repeated often enough: The meltdown/spectre patches are vital to keeping your PC and data safe, and disabling them will expose your computer to these vulnerabilities. Follow the below advice at your own risk. Any damage, loss of data, or any other negative outcome is your own responsibility. You have been warned.

If your concerns are genuine, however, such as your work is impacted by serious penalties on build/compilation time, IDE performance, etc. your solution is fortunately quite simple.

The current, or perhaps some future patches will eventually become part of the kernel, so you might want to HODL your current kernel after doing this, like it was some fancy new crypto, until everything properly settles or you can buy a less affected CPU.

Four colourful notices later, The Solution

The current patches can be disabled with simple kernel command line parameters. (Yay!) This RedHat KB article explains the three main performance hogs and how they can be disabled, while this Ubuntu wiki article lists all relevant tunables, so that you can cherry-pick what is loaded, depending on your situation/evaluation.

The three most common performance "offenders", as per the above RH article are:

  • Page Table Isolation (pti) — Use the parameter nopti or pti=off to disable it
  • Indirect Branch Restricted Speculation (ibrs) — Use the parameter noibrs to disable it
  • Indirect Branch Prediction Barriers (ibpb) — Use the parameter noibpb to disable it

The simplest way to do this (for GRUB/2) is to edit /etc/default/grub with your favourite editor, something like:

sudo micro /etc/default/grub

(You can, of course, use nano, vi(m), and even emacs, if you feel masochistic, or whatever you fancy, this is just a text file)

...then change the line where it says GRUB_CMDLINE_LINUX_DEFAULT from something like:


(It might not look exactly like that, but you being a developer n'all should already know this) something like:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nopti noibrs noibpb"

(Of course you want to keep the original parameters, because why wouldn't you wanna keep them.)

...then update grub with:

sudo update grub


sudo update-grub2

depending on your setup.

If you're not loading with GRUB/2, you can find the most detailed guide to kernel parameters known to man on the Arch Linux Wiki, right here, with generic kernel boot-parameter instructions for just about any possible scenario.

And that's it. Reboot, and your PC should have its old performance once again. Now get back to work, but only afer you've shared this article on your favourite social media platform.

Happy coding. :)

Liked what you've read? Sharing this article on your favourite social medium helps a lot with discoverability. You know, sharing is caring.

Got something to add? Comment is free, so please leave your thoughts below, and don't forget to "like"/recommend it on Disqus.

Want to stay up-to-date? Subscribe to the RSS or Atom feed, so you will always know about new content first-hand.

Similar posts


Tell us what you think

Blog Comments powered by Disqus.