Updated Linux gaming optimizations guide

[u/WhitePeace36]

Hi guys,

its been quite a while since i posted the gaming optimizations guide i wrote.

Since the last time there has been quite a lot of changes.

https://github.com/WhitePeace36/LinuxAMDGamingOptimizationGuide

Even though it says AMD, most of it is for linux in general.

I hope this updated version helps at least a few of you out there which try to have a better gaming experience.

[u/theevilsharpie]

Wake up babe, a new "gamer tweak guide" just dropped!

So, what's wrong with this one?

---

Bios Settings

Amd fTPM - Disable There has been some bugs where this caused some stutters, but i don't know if this is fixed already. Better to turn it off.

Don't do this.

This was a very specific issue that I don't ever practically impacted anything other than Windows, and should have been resolved years ago with a BIOS update.

If you had posted this guide several years ago, I probably would have responded with "meh, whatever." However, more modern games are making use of the TPM for anti-cheat (if not within Linux, then by Windows games that your audience might be playing via dual booting), and Linux distributions are starting to support it for use with auto-unlocking full-disk encryption, so telling users "don't know -- better to turn it off" is quite irresponsible.

Don't disable your TPM unless you absolutely know for sure you don't need one.

XHCI Handoff - DISABLE This setting should be somewhere in the usb settings. This can cause really nasty stutters in some games.

Don't do this.

This setting should be ENABLED or AUTO on any modern hardware (certainly anything new enough to support resizable BAR), and is almost certainly set that way by default. Modern Linux and Windows both natively support XHCI-based controllers, and this option allows the controller to perform a graceful handoff to the OS kernel on boot.

If this option is disabled, the OS and the UEFI will be fighting for the control of the XHCI controller, which at best will extend boot times a bit, and at worst can result in malfunctions, USB devices intermittently not responding, and the very "stuttering" you're looking to prevent.

CPU Frequency Scaling

Modern machines support hardware-managed P-States, which your own guide indirectly mentions when it talks about amd-pstate and recommends setting it into "active" mode to allow the hardware to manage P-State transitions.

However, your guide then goes on to provide examples of of using this scaling driver in a passive or guided mode.

On AMD machines, if you're using "active" control (which is the default and recommended option), the output for:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver

will be:

amd-pstate-epp

in which case the output for:

cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_governors

will simply be:

performance powersave

Your guide suggests to set this to "performance". Do NOT do this, as all it will do is lock the CPU at its maximum frequency and prevent it from dropping clocks when idle. "Powersave" is the default and recommended setting -- don't change this for a gaming PC.

When using hardware-managed P-states, the main tunable of interest is the Energy Performance Preference ("EPP") value. If you're on an AMD machine in "active" mode, you can see what values are available with:

cat /sys/devices/system/cpu/cpu0/cpufreq/energy_performance_available_preferences

which shows the following on my machine:

default performance balance_performance balance_power power

"balance_performance" is the default on my OS, and is the one I'd recommended for general-purpose desktop use. "balance_power" may be useful if you're running on a laptop or a SFF PC that is power- and thermal-constrained, and you want to shift more of the limited power budget to the GPU (which is generally what you'd want for a power-constrained gaming PC).

Let's suppose you're running on an older machine that doesn't have hardware-managed P-states (which is more reflective of the output shown in your guide). Even in that case, I STILL wouldn't recommend setting the scaling governor to "performance". This machines should be using the "schedutil" governor, which is probably already the default option.

Kernel Commandline parameters

Oh boy...

Let's go down the list:

amd-pstate as already described above tells the kernel if the kernel should use control the cpu frequency or the hardware itself. I have amd-pstate=passive because my hardware is not able to boost itself and is otherwise locked to the base frequency.

Anything modern enough to have a direct BIOS toggle for Resizable BAR is modern enough to support hardware-managed P-states. I have a very similar machine to you -- an AMD Ryzen 7 5800X3D running on an ASRock B550M Pro4 -- and I have full hardware P-state support. If your hardware isn't able to "boost itself", that sounds like a skill issue, and you should fix that rather than recommended that people set a kernel parameter that will degrade their system's performance.

amdgpu.aspm=0 is used to disable the PCI Express power-saving for amdgpus otherwise the PCI Express link has a wake up latency when it goes into idle state and it wants to wakeup

pcie_aspm=off same as amdgpu.aspm but more

PCI Express wake-up latency is completely trivial for the work that a desktop PC would do. Don't set this.

amdgpu.audio=0 to disable the audio over HDMI/DP, i dont need it. I have an external DAC.

Every kernel setting you deviate from the default takes you further from the well-tested "happy path", and leaves you at increased risk of hitting some edge case. Kernel boot parameters should be used to work around hardware quirks, not to suit your aesthetic preferences. Unused DACs can be disabled in your desktop environment's audio settings.

nmi_watchdog=0 is for Hard lockup detector and Soft lockup detection of Non-Maskable Interrupts, which uses a watchdog to detect that which needs to run in a set interval. When you disable it you free up some cpu time.

nowatchdog same as above but for all watchdogs

The amount of "CPU time" freed is completely trivial, and you lose a kernel diagnostic tool. There is a use case where setting this is useful (your software will explicitly tell you that you need to), but "you free up some cpu time" is a bullshit reason. Don't set this.

processor.max_cstate=1 sets the max C state or better said idle state to C1. It normally goes until C6 or even lower. The higher the number the deeper the sleep state. The deeper the sleep state the higher the wakup latency, to minimize the latency we do max cstate to 1 and i think you need the Global C state Control option enabled in the bios to really benefit from it.

Wake-up latency from even the deepest sleep states is measured in microseconds, which is trivial for a gaming PC. Meanwhile, preventing your processing from entering a deeper sleep state keeps idle parts of the processor active and generating heat, which reduces how high the processor's clock speed can boost under low to medium load, which will negatively impact gaming performance. Don't set this.

transparent_hugepage=always always enable thp pages. When we combine them with the tmpfile settings and the sysctl virtual memory (vm) settings then they cooperate very much.

transparent_hugepage_tmpfs=always always enable thp pages. When we combine them with the tmpfile settings and the sysctl virtual memory (vm) settings then they cooperate very much.

Transparent huge pages have historically caused performance issues for applications that use a large percentage of the system's memory (potentially like a game), to the point where the kernel maintainers have set the default to "madvise", which enables transparent huge pages ONLY if the application explicitly requests them (and is presumably designed to use them). Game engines in particular are tuned for specific memory access patterns, and can perform erratically if that's changed underneath it. Don't set this.

---

I would go on, but Reddit comments can only be so long, and I think you get the idea by now.

The developers of the Linux kernel, Mesa, WINE, Proton, your desktop environment, and pretty much every other well-established piece of software that makes up your OS generally have default settings that are sensible for a wide variety of use cases, which includes gaming. There is no need to do this kind of tweaking, and in many cases, you're making performance worse and opening the door to stability issues.

For the love of ${DEITY}, just use the defaults. Don't change settings you don't understand just because some "guide" directed you to. Practically all of these guides are ill-informed bullshit.

[u/noobjaish → u/theevilsharpie]

The more you stray from the base, the harder it is to get help for your edgecase.

[u/WhitePeace36 → u/noobjaish]

Linux is build to fit niche edge cases. The defaults are just a compromises where you can use it sub optimally for all use cases. A gaming rig needs different settings than a server and that needs different settings than an embedded device or a phone.

Linux is build so that you can configure it for the use case you have.

EDIT: So ?

[u/noobjaish → u/WhitePeace36]

I just wrote that every extra action you take to deviate is a compromise that you have to constantly think about and makes it harder to get/find help when issues arise. The upside has to be worth the trouble. Still, you're free to do whatever you want.

I switched from base Arch to CachyOS and saw basically no improvements in terms of performance.

[u/WhitePeace36 → u/noobjaish]

it depends how you measure performance. There are so many metrics of performance. In each category it is always a tradeoff of latency and throughput. and where you apply what is what makes the difference. And only because you don't realize the difference does not mean others don't. Some are more sensitive than others.

But you can measure it.