Below are the best settings I've found so far. This is with amd hardware, so I dont have any insights into nvidia settings for optimal performance.
Software:
This is with linux 6.5 (custom built), proton experimental thru steam. amd radv drivers using kde plasma wayland (for it's freesync support - if you dont have a vrr monitor, use whatever desktop you want). I'm using debian unstable with mesa 23.1.6
Hardware:
3900x ryzen cpu, and 7900xt radeon gpu. 64gb 3200mhz ddr4 and nvme's all around currently benching at > 1GiB/sec transferrates. cpu is water cooled and temps are not an issue for any of the components in question - including the nvme's.
Graphics benchmarks show everything is operating where it should be in comparison to others with the same hardware.
These tweaks were done to deal with what is a very cpu bound performance bottleneck with the game. At 1440 ultra settings in elite, my gpu was only being 40-50% utilized in res sites. Yet, i was seeing poor and inconsistent framerates in parts of the game i would not expect (not surfaces). Poor being drops into the 60's and generally just varying between 120 and 60 as you move the camera around while being stationary in the roid field.
#1. Set your scheduler to performance mode while playing.
I have always played with my cpu scheduler set to "ondemand" but as time has progressed, it seems the algorithms impacting scheduling has led to issues with steam games not triggering max frequency. I was seeing cpu maxing at < 4Ghz even though it should be hitting 4.6ish.
#2. Set the following boot args in your grub configuration: mitigations=off tsc=reliable clocksource=tsc split_lock_detect=off
If you dont already exclude compiling all of the side-channel mitigations when building your kernel, then you want to disable them at boot up. Most gaming machines wont be vulnerable to them in the real world and their impact on performance is not insignificant.
tsc and clocksource arguments ensure you dont use hpet, which while being far more precise as a clock, is also far more time consuming to call (like literally hundreds of times slower). Games make a lot of frequent time syscalls, and tsc isn't as garbage of a clock source as it once was on modern hardware. Bonus, by not using hpet as your time source, you pretty much mitigate most side channel attacks anyway for free, since they rely on very accurate timing.
split_lock_detect is a feature that was recently added to the linux kernel to punish applications that abused what should be atomic locks and caused extremely poor and cpu blocking performance issues for other processes. What current kernels do is basically throttle those processes so they dont harm other processes with their poor implementation. But games seem to be a notable offender. Fortunately, while playing games, we generally dont care about the performance of other applications. Unfortunately though, there doesn't appear to be an easy way (that i'm aware of) to disable this function in sysfs at runtime or per process, so i just disable it at boot.
#3 sysctl -w vm.max_map_count=2147483642
Set this at runtime or in a sysctl config file if your distro doesn't already set it to a sufficiently large number.
The combination of the above items (and i tried just the scheduler change to no avail) successfully reduced the cpu bottleneck i was experiencing that was limiting me to 100fps or less in res sites to a steady 144 (my current limiter)
Launching the game with launch arguments DXVK_HUD=full %command% will let you monitor your gpu side of things when testing the above. If you're seeing near 100% gpu usage, then the above options may not do much for you since you will be gpu bound in your performance and not cpu. If you are seeing poor framerate and like < 75% gpu usage then you are cpu bound and may benefit from the above changes.
Chime in with any other kernel/system configs that have been found to improve performance.
FYI, I left out using corectl to overclock amd gpu's because the 7900 isn't supported yet. But if you have a 6000 series card or older, you probably can use it to overclock and that will be beneficial obviously, especially if you are gpu bound. the 7900xt (on most cards) seems limited to 290watt tdp in linux (2.92Ghz clock). This is temporary (presumably), and it's expected that eventually we'll have the ability to set the tdp to what it can be set to in windows (i think it's around 320watt). Some brands of the card may come overclocked by default though and you wont be impacted by this issue.
edit: these settings also seem to to noticeably improve VR performance, though VR tends to be much more gpu bound than cpu, so the effect is mostly around improving the reduction of low framerate drops rather than pushing the avg max framerate higher if you're not pegging your limiter. I found motion to be smoother and framerate more stable at my limiter of 90fps in res sites than without these settings. This made odyssey feel like the days of old horizons gameplay ...though i've replaced my hardware with much better stuff since then.
edit 2: other interesting thing I've noticed is that setting cpu governor to performance prior to starting elite (the game, not the launcher) ... can result in poor framerate despite the cpu being at top freq. setting it after starting works.
Software:
This is with linux 6.5 (custom built), proton experimental thru steam. amd radv drivers using kde plasma wayland (for it's freesync support - if you dont have a vrr monitor, use whatever desktop you want). I'm using debian unstable with mesa 23.1.6
Hardware:
3900x ryzen cpu, and 7900xt radeon gpu. 64gb 3200mhz ddr4 and nvme's all around currently benching at > 1GiB/sec transferrates. cpu is water cooled and temps are not an issue for any of the components in question - including the nvme's.
Graphics benchmarks show everything is operating where it should be in comparison to others with the same hardware.
These tweaks were done to deal with what is a very cpu bound performance bottleneck with the game. At 1440 ultra settings in elite, my gpu was only being 40-50% utilized in res sites. Yet, i was seeing poor and inconsistent framerates in parts of the game i would not expect (not surfaces). Poor being drops into the 60's and generally just varying between 120 and 60 as you move the camera around while being stationary in the roid field.
#1. Set your scheduler to performance mode while playing.
I have always played with my cpu scheduler set to "ondemand" but as time has progressed, it seems the algorithms impacting scheduling has led to issues with steam games not triggering max frequency. I was seeing cpu maxing at < 4Ghz even though it should be hitting 4.6ish.
#2. Set the following boot args in your grub configuration: mitigations=off tsc=reliable clocksource=tsc split_lock_detect=off
If you dont already exclude compiling all of the side-channel mitigations when building your kernel, then you want to disable them at boot up. Most gaming machines wont be vulnerable to them in the real world and their impact on performance is not insignificant.
tsc and clocksource arguments ensure you dont use hpet, which while being far more precise as a clock, is also far more time consuming to call (like literally hundreds of times slower). Games make a lot of frequent time syscalls, and tsc isn't as garbage of a clock source as it once was on modern hardware. Bonus, by not using hpet as your time source, you pretty much mitigate most side channel attacks anyway for free, since they rely on very accurate timing.
split_lock_detect is a feature that was recently added to the linux kernel to punish applications that abused what should be atomic locks and caused extremely poor and cpu blocking performance issues for other processes. What current kernels do is basically throttle those processes so they dont harm other processes with their poor implementation. But games seem to be a notable offender. Fortunately, while playing games, we generally dont care about the performance of other applications. Unfortunately though, there doesn't appear to be an easy way (that i'm aware of) to disable this function in sysfs at runtime or per process, so i just disable it at boot.
#3 sysctl -w vm.max_map_count=2147483642
Set this at runtime or in a sysctl config file if your distro doesn't already set it to a sufficiently large number.
The combination of the above items (and i tried just the scheduler change to no avail) successfully reduced the cpu bottleneck i was experiencing that was limiting me to 100fps or less in res sites to a steady 144 (my current limiter)
Launching the game with launch arguments DXVK_HUD=full %command% will let you monitor your gpu side of things when testing the above. If you're seeing near 100% gpu usage, then the above options may not do much for you since you will be gpu bound in your performance and not cpu. If you are seeing poor framerate and like < 75% gpu usage then you are cpu bound and may benefit from the above changes.
Chime in with any other kernel/system configs that have been found to improve performance.
FYI, I left out using corectl to overclock amd gpu's because the 7900 isn't supported yet. But if you have a 6000 series card or older, you probably can use it to overclock and that will be beneficial obviously, especially if you are gpu bound. the 7900xt (on most cards) seems limited to 290watt tdp in linux (2.92Ghz clock). This is temporary (presumably), and it's expected that eventually we'll have the ability to set the tdp to what it can be set to in windows (i think it's around 320watt). Some brands of the card may come overclocked by default though and you wont be impacted by this issue.
edit: these settings also seem to to noticeably improve VR performance, though VR tends to be much more gpu bound than cpu, so the effect is mostly around improving the reduction of low framerate drops rather than pushing the avg max framerate higher if you're not pegging your limiter. I found motion to be smoother and framerate more stable at my limiter of 90fps in res sites than without these settings. This made odyssey feel like the days of old horizons gameplay ...though i've replaced my hardware with much better stuff since then.
edit 2: other interesting thing I've noticed is that setting cpu governor to performance prior to starting elite (the game, not the launcher) ... can result in poor framerate despite the cpu being at top freq. setting it after starting works.
Last edited: