How to optimize performance on desktop OpenBSD

If there is something I don't like on OpenBSD, then it is lack of information when it comes to problem solving. The main reason, of course, is the size of the OpenBSD community. But even when I try to target the community on the main communication channels like IRC, or Mastodon, I often don't get the answer I am looking for. Therefore, I decided to do it another way. Research the topic, make a blog post, publish it and let people only comment on what is wrong and what is missing. For most people, it is more fun to correct someone, than to prepare the full response to the question.

Problem

The first problem which I will cover in this article is that OpenBSD is slow. You won't notice that much on the server without heavy IO/load/multiprocessing, but you will definitely feel the huge performance gap on a desktop. You can feel it even if your setup is completely minimalistic like mine (dwm + mostly terminal). The boot of the OS is several times slower than Linux/Windows. I have also measured application starts and usage against a Gentoo Linux deployed on the same machine. The machines were Thinkpad X230, Thinkpad X1C6 and an Alderlake high performance desktop. Tested Applications were Chromium, Firefox, Libreoffice, Gimp and IntelliJIdea, which are most of the time the only applications I use out of terminal. Results were from 50% to several hundred percent worse in the case of OpenBSD. Internet browsing is also slower on both main browsers. I have done the tests on wired connection, because it is known that wireless performance on OBSD is worse. These measures were not super exact, but they support the point. If you want some less real world and more precise tests supporting the claim, check this Phoronix article

Why is it slow

• IO & FFS. This is probably the biggest reason for bad desktop performance. FFS is slower than modern filesystems and IO operations are drastically slower. So, in the case of applications that work with significant amounts of small files or caches, the performance will be bad. These applications often fight this problem with parallelisation, but process management is also slower on OBSD, which makes the resulting performance even worse. There is a detailed test from 2018 in another Phoronix article regarding IO. I would guess it is still relevant even 5 years later, as there wasn't much work done on FFS between 2018-2023. Not sure about general IO performance. FreeBSD, for example, adopted ZFS to mitigate these issues. The current official statement regarding adopting some modern filesystem is that there is no need for it. So be prepared for some more years with FFS.

• HyperThreading is disabled by default. This is a security precaution. In the Linux world it is also recommended to do it, but it is not forced as a default option. You can enable SMT in OpenBSD too, if you want. But it won't make much of a difference overall.

• Kernel. OpenBSD is all about security, but also about simplicity. A small dev team means you have to choose wisely what new complexity you want to add, because then it will have to be maintained. This is why the FFS is still the default and only primary filesystem. That is also the reason why the OBSD kernel is a tick kernel. Most of the modern kernels are tickless and therefore more performant, but by going tickless, you are adding more complexity. The same applies to the locking mechanism. It is still the same tradeoff question. But afaik, there have been steady improvements during the past years. At least in the case of locking.

• Wifi. There is no 802.11ac and 802.11ax support. Some drivers declare compatibility with it, but they run in N or G mode after connecting. Full support for 802.11ax or even 802.11ac probably won't come in future years due to the small number of developers focusing on drivers and also due to the fact that 802.11ac and 802.11ax specifications are much more complex and therefore difficult to implement. You can check the state of support for your chipset in the official handbook

• Security. Everything that process wants from the Kernel or the OS in general is checked and controlled in a more strict way. More checks and locks means more time to deliver CPU time or resources which the process asked for. This then becomes the rolling snowball. Especially in modern robust multiprocessing software. This is not a bug, but a feature in OpenBSD and therefore, one should not expect that performance will be prioritized in this case.

Solution

There is no real solution to this problem. Most of the issues we went through boil down to being that way by design, or there is no manpower/will to adopt more robust alternatives, which would increase maintenance cost and code complexity. It would be great if the OpenBSD performance would be on par with Linux, but it won't happen. If the performance has higher priority than simplicity and additional security in your case, then you should probably use a different OS. But if you're here to stay like I do, then there are some partial improvements you can apply:

• Enable soft updates by adding softdep in your /etc/fstab. Before you do so, read the potential cons of turning soft updates on.
• Disable atime by adding noatime in your /etc/fstab
• /tmp and ~/.cache dirs reconfiguration from standard FFS to ramdisks
• If you don't mind the security recommendations, then turn on HT in sysctl: hw.smt=1
• Reconfigure limits for your user in /etc/login.conf to higher values
• Enable apmd (power management) and set to auto or max performance
• Use wired connection if possible and if you can, choose best supported wireless chipset
• Make sure you have direct rendering enabled like this for example: glxinfo | grep "direct rendering"
• Chromium does perform better than Firefox. If you're stuck with Firefox, be sure to:
  • turn on layers.acceleration.force-enable in about:config
  • turn on gfx.webrenderer.enable in about:config
• Use h264ify browser extension to force switch to H264 encoding as it has better playback performance
• Playing videos on internet works better through mpv than through browser. you can also use ytfzf to browse youtube from terminal
• Use lightweight window manager (dwm, cwm, i3, fluxbox...)

Errata & corrigenda

• Solène Rapenne pointed out, that using apmd has no sense nowadays, because CPU speed is by default set to maximum and the frequency scheduling should be done on the hardware side. (sometimes badly)
• Solène Rapenne also mentioned, that there is a significant performance increase for GTK4 applications coming to OpenBSD 7.3 due to some shaders re-computing optimisations. So using Gnome might be an option soon.
• Stefan Sperling provided up-to-date status for wifi drivers.
  • By default, all drivers are 802.11a/b/g only (with 4 exceptions)
  • athn(4) has preliminary 802.11n support (no Tx aggregation and no 40MHz channels)
  • bwfm(4), iwm(4), iwx(4) have stable 802.11n and also 802.11ac support with up to 300Mbit/s download speeds. There is still some tuning possible (larger frame aggregates, 160MHz channel support, A-MSDU support in Tx), but current performance is satisfactory for now.
• Stuart Henderson explains pros and cons of using noatime and softdep in this email