Our kernel is hosted here on copr:
https://copr.fedorainfracloud.org/coprs/sentry/kernel-fsync/
The patches are noted in the spec sheet:
Patch200: tkg.patch
Patch202: fsync.patch
Patch203: OpenRGB.patch
Patch206: amdgpu-si-cik-default.patch
device specific patches
Patch300: linux-surface.patch
Patch301: steam-deck.patch
(1) Regarding winesync/fsync/futex2:kernel patched with futex2
kernel patched with fsync compatibility
kernel patched with winesync
The kernel has already been patched upstream with fsync (5.16) + futex2 (5.17). Both ‘fsync’ and ‘winesync’ were superseded by futex2 patches in the kernel in 5.17.4. The remaining ‘fsync’ patch adds backwards-compatibility so that older versions of proton which do not support futex2 can still run fsync. Basically you can think of these as fsync version 1 and fsync version 2. Winesync was a proposal that never came to fruition due to the mentioned superseding by futex2. The original proposal can be found here:
https://lore.kernel.org/lkml/[email protected]/T/#u
The benefit of all fsync + futex2 is a large uplift in game framerates. The benefit of the remaining fsync.patch we apply is as mentioned for backwards compatibility. I am unaware of why this last patch was not submitted upstream or if it is pending.
(2) Regarding cherry-picked performance patches:kernel patched with cherry-picked zen patches
This is a set of patches from ‘TKG’ (Etienne Juvigny) who performs similar gaming related optimizations/fixes that I do, but on Arch:
https://github.com/Frogging-Family/linux-tkg
They are contained in tkg.patch. They are a mix-mash of cherry picks from the liquorix and clear linux kernels, with a few game-performance specific additional patches. Again — the state of getting these upstreamed is unknown. The patches are noted as follows with subjects that are mostly self-explanatory in regards to what they do and/or their performance benefits:
From: Alexandre Frade [email protected]
Date: Mon, 29 Jan 2018 16:59:22 +0000Subject: [PATCH 02/17] dcache: cache_pressure = 50 decreases the rate at which VFS caches are reclaimed
From: Alexandre Frade [email protected]
Date: Mon, 29 Jan 2018 18:29:13 +0000Subject: [PATCH 03/17] sched/core: nr_migrate = 128 increases number of tasks to iterate in a single balance run.
From: Etienne Juvigny [email protected]
Date: Mon, 3 Sep 2018 17:36:25 +0200
Subject: [PATCH 07/17] Zenify & stuff (“A selection of patches from Zen/Liquorix kernel and additional tweaks for a better gaming experience”)
Tunes the kernel for responsiveness at the cost of throughput and power usage.
--- Virtual Memory Subsystem ---------------------------
Mem dirty before bg writeback..: 10 % -> 20 %
Mem dirty before sync writeback: 20 % -> 50 %
--- Block Layer ----------------------------------------
Queue depth……………: 128 -> 512
Default MQ scheduler……: mq-deadline -> bfq
--- CFS CPU Scheduler ----------------------------------
Scheduling latency………….: 6 -> 3 ms
Minimal granularity…………: 0.75 -> 0.3 ms
Wakeup granularity………….: 1 -> 0.5 ms
CPU migration cost………….: 0.5 -> 0.25 ms
Bandwidth slice size………..: 5 -> 3 ms
Ondemand fine upscaling limit..: 95 % -> 85 %
--- MuQSS CPU Scheduler --------------------------------
Scheduling interval…………: 6 -> 3 ms
ISO task max realtime use……: 70 % -> 25 %
Ondemand coarse upscaling limit: 80 % -> 45 %
Ondemand fine upscaling limit..: 95 % -> 45 %
From: Steven Barrett [email protected]
Date: Sun, 16 Jan 2011 18:57:32 -0600
Subject: [PATCH 08/17] ZEN: Allow TCP YeAH as default congestion control
4.4: In my tests YeAH dramatically slowed down transfers over a WLAN,
reducing throughput from ~65Mbps (CUBIC) to ~7MBps (YeAH) over 10 seconds (netperf TCP_STREAM) including long stalls.
From: Steven Barrett [email protected]
Date: Wed, 28 Nov 2018 19:01:27 -0600
Subject: [PATCH 09/17] zen: Use [defer+madvise] as default khugepaged defrag
strategy
For some reason, the default strategy to respond to THP fault fallbacks
is still just madvise, meaning stall if the program wants transparent
hugepages, but don’t trigger a background reclaim / compaction if THP
begins to fail allocations. This creates a snowball affect where we
still use the THP code paths, but we almost always fail once a system
has been active and busy for a while.
The option “defer” was created for interactive systems where THP can
still improve performance. If we have to fallback to a regular page due
to an allocation failure or anything else, we will trigger a background
reclaim and compaction so future THP attempts succeed and previous
attempts eventually have their smaller pages combined without stalling
running applications.
We still want madvise to stall applications that explicitely want THP,
so defer+madvise does make a ton of sense. Make it the default for
interactive systems, especially if the kernel maintainer left
transparent hugepages on “always”.
Reasoning and details in the original patch:
https://lwn.net/Articles/711248/
From: Alexandre Frade [email protected]
Date: Wed, 24 Oct 2018 16:58:52 -0300
Subject: [PATCH 10/17] net/sched: allow configuring cake qdisc as default
https://www.bufferbloat.net/projects/codel/wiki/CakeTechnical/
From: Tk-Glitch [email protected]
Date: Mon, 18 Feb 2019 17:40:57 +0100
Subject: [PATCH 11/17] mm: Set watermark_scale_factor to 200 (from 10)
Multiple users have reported it’s helping reducing/eliminating stuttering with DXVK.
From: Tk-Glitch [email protected]
Date: Fri, 19 Apr 2019 12:33:38 +0200
Subject: [PATCH 12/17] Set vm.max_map_count to 262144 by default
The value is still pretty low, and AMD64-ABI and ELF extended numbering
supports that, so we should be fine on modern x86 systems.
This fixes crashes in some applications using more than 65535 vmas (also affects some windows games running in wine, such as Star Citizen).
From: Tk-Glitch [email protected]
Date: Mon, 27 Jul 2020 00:19:18 +0200
Subject: [PATCH 13/17] mm: bump DEFAULT_MAX_MAP_COUNT
Some games such as Detroit: Become Human tend to be very crash prone with lower values.
From: Alexandre Frade [email protected]
Date: Mon, 25 Nov 2019 15:13:06 -0300
Subject: [PATCH 14/17] elevator: set default scheduler to bfq for blk-mq
Signed-off-by: Alexandre Frade [email protected]
From: Alexandre Frade [email protected]
Date: Mon, 3 Aug 2020 17:05:04 +0000
Subject: [PATCH 16/17] mm: set 2 megabytes for address_space-level file
read-ahead pages size
Signed-off-by: Alexandre Frade [email protected]
From: Steven Barrett [email protected]
Date: Wed, 15 Jan 2020 20:43:56 -0600
Subject: [PATCH 17/17] ZEN: intel-pstate: Implement “enable” parameter
If intel-pstate is compiled into the kernel, it will preempt the loading
of acpi-cpufreq so you can take advantage of hardware p-states without
any friction.
However, intel-pstate is not completely superior to cpufreq’s ondemand
for one reason. There’s no concept of an up_threshold property.
In ondemand, up_threshold essentially reduces the maximum utilization to
compare against, allowing you to hit max frequencies and turbo boost
from a much lower core utilization.
With intel-pstate, you have the concept of minimum and maximum
performance, but no tunable that lets you define, maximum frequency
means 50% core utilization. For just this oversight, there’s reasons
you may want ondemand.
Lets support setting “enable” in kernel boot parameters. This lets
kernel maintainers include “intel_pstate=disable” statically in the
static boot parameters, but let users of the kernel override this
selection.
(3) Regarding OpenRGB:kernel patched with OpenRGB
This is a kernel-side patch which correlates with usage of OpenRGB, found here:
https://gitlab.com/CalcProgrammer1/OpenRGB
It is used for controlling various RGB devices (RAM, Fans/Fan Controllers, Motherboard LEDs and so on). The patch is specifically for i2c-nct6775:
Add timeouts to i2c-nct6775 driver and fix kernel segfault caused by byte access with no data
This is mainly to provide a better out of the box cosmetic experience on RGB rainbow-barf systems.
(4) Regarding AMD CPCC:kernel patched with AMD CPCC
This is no longer relevant as AMD CPCC was merged upstream in kernel 5.17
(5) Regarding amdgpu:kernel patched to enable amdgpu for pre-polaris cards by default instead of radeon
This is handled by amdgpu-si-cik-default.patch. By default, with cards from the radeon R9 series and older, the ‘radeonsi’ driver is chosen instead of amdgpu. This leads to a very bad out of the box experience because radeonsi is not receiving any new work/updates. All of the GPU related work, even for older generations, has been going into the amdgpu driver for several years now. radonsi cannot use vulkan while amdgpu can. By setting the default driver for these legacy cards to ‘amdgpu’ it allows them to work out of the box when gaming. The drawback, and reason it was not accepted upstream, is because amdgpu does not support analog output, however on most cards the dvi output is digital, and most of those cards also come with hdmi/displayport options as well. The proposal was originally noted here:
Proposal:
https://lists.freedesktop.org/archives/amd-gfx/2020-August/052243.html
Blockers:
https://lists.freedesktop.org/archives/amd-gfx/2020-August/052276.html
(6) Regarding steam deck:kernel patched with steam deck support
This was requested with the popularity of the steam deck. Given I don’t expect anyone to run Nobara on the steam deck, the option is there should they choose to do so. It provides hardware support for the steam deck. Again — I don’t know if these have been upstreamed.
(7) Regarding waydroid:kernel configured with ashmem, binder, and android support for Waydroid
We are looking actively at Waydroid support too, but does this have any advantage beyond that?
As far as I’m aware these are just for android support. I don’t know of any other use case.
(8)kernel patched with windows surface support
The patches for this come from here:
https://github.com/linux-surface/linux-surface
They were requested by Strider (Lutris developer). Again, unaware if any upstream effort is being made. They do provide some additional insightful instructions for Fedora usage:
https://github.com/linux-surface/linux-surface/wiki/Installation-and-Setup
(9)mesa-git provided for AMD/Intel drivers instead of latest release, built and updated regularly (every few weeks to a month on average)
Would you be willing to host this git driver snapshot as a COPR that we could then offer somehow in Fedora Workstation too?
I’ve already been doing so for several years:
https://copr.fedorainfracloud.org/coprs/gloriouseggroll/mesa-aco/
However please note that occasionally I add custom pending patches/pull requests to allow games to work. (This is rare, usually happens if a game is completely broken or needs a revert or needs some new feature)
(10)glibc patched with clone3 disabled (fixes CEF compatibility in applications using outdated CEF such as Discord, Steam beta)
glibc patched with broken commits reverted to allow EasyAntiCheat to work for Rogue Company
copr hosted here:
https://copr.fedorainfracloud.org/coprs/gloriouseggroll/glibc/
The clone3 issue is an issue with 3rd party developers using old/outdated CEF. Ubuntu has already patched it the same way:
https://github.com/ValveSoftware/steam-for-linux/issues/8373#issuecomment-1030509625
*The Rogue Company glibc issue needs a bug open upstream, I bisected it fairly recently:
https://github.com/ValveSoftware/Proton/issues/5214#issuecomment-1146697262
It appears the changes that caused the breakage were made for packaging reasons:
glibc: Avoid the need for manually running ldconfig after downgrade
https://bugzilla.redhat.com/show_bug.cgi?id=1652867
(11)openal version updated (fixes CSGO intro video crash)
No longer relevant, fixed in openal version shipped with f36
(12)dnf fastestmirror enabled
dnf max parallel downloads increased to 6
This is just a custom preference to make dnf downloading not slow as dirt:
From b70be537219c9ddbac012c26c42f628225eefa59 Mon Sep 17 00:00:00 2001
From: Thomas Crider [email protected]
Date: Wed, 18 May 2022 14:13:48 -0600
Subject: [PATCH] Enable fastest mirror by default and increase parallel
downloads to 6
etc/dnf/dnf.conf | 2 ++
1 file changed, 2 insertions(+)
diff --git a/etc/dnf/dnf.conf b/etc/dnf/dnf.conf
index 460dd25..9fa4a23 100644
--- a/etc/dnf/dnf.conf
+++ b/etc/dnf/dnf.conf
@@ -6,3 +6,5 @@ installonly_limit=3
clean_requirements_on_remove=True
best=False
skip_if_unavailable=True
+fastestmirror=1
+max_parallel_downloads=6
2.36.1
(13)gst-editing-services disabled — causes WINE to hang when creating new prefixes
This is a known issue:
https://github.com/Frogging-Family/wine-tkg-git/issues/396
https://bugs.winehq.org/show_bug.cgi?id=52009
(14)libusb fix for high CPU usage when using xow/xone wireless xbox controller service:
https://github.com/medusalix/xow/issues/141
No longer relevant, fixed in libusb version shipped with f36
(15)lspci symlink from /usr/sbin/lspci to /usr/bin/lspci for Dying Light:
https://www.gamingonlinux.com/forum/topic/2766/post_id=17381
I tried reporting this back in Fedora 32, they blamed it on the game developer and marked it NOTABUG:
https://bugzilla.redhat.com/show_bug.cgi?id=1858437
It remains broken to this day.
(16)edk2 patched to fix VFIO issue
https://github.com/tianocore/edk2/commit/ee1f8262b83dd88b30091e6e81221ff299796099
No longer relevant, fixed in edk2 version shipped with f36
(17)xone xbox wireless usb dongle kernel module packages installed (the firmware requires lpf, please see notes at the bottom)
Are there licensing issues here causing this not to be in Fedora?
We ship both xone and xpadneo:
xone requires additional firmware to be installed. Nobara has a run-on-login script that it runs for hardware that needs 3rd party drivers:
When the user logs in, it uses zenity and provides a pop up asking if they want to install those drivers. This way we get user acknowledgement that they agree to install the firmware, and it is not being forced on them or violating any licenses. For xone the firmware is installed via lpf once the user agrees. For xpadneo no drivers/firmware are required beyond the open source kernel driver it provides.
(18)gnome variable refresh rate patches added for mutter:
https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1154
This is pending upstream work that will likely make it into the next mutter release
(19)gamescope version regularly updated
goverlay version regularly updated
mangohud version regularly updated
vkbasalt version regularly updated
These are already provided by Fedora, however they stick to the major versions, which can cause problems and miss out on features. In particular gamescope and mangohud have constant changes/fixes being applied regularly, they need to be monitored and updated frequently.
(17)abi.vsyscall32 = 0 set by default for League of Legends
This is required for League of Legends. There used to be a workaround using a glibc patch instead, but it stopped working after a recent LoL update. Details here:
From what I’ve seen the performance impact on 32 bit games/applications is not noticeable. This is done here:
(18)vm.max_map_count = 16777216 set by default for Star Citizen
Note: file limit changes are -not- needed on Nobara for Star Citizen because the default is 1048576 which is larger than the required amount ‘524288’:
https://github.com/starcitizen-lug/lug-helper/blob/c627666705994a2fe3a2bb396a289e625c3abf2b/lug-helper.sh#L697
Star citizen has some ‘special’ requirements — this being one of them. We have a kernel patch mentioned earlier that already increases this value, but I’ve found sometimes it’s not enough:
From: Tk-Glitch [email protected]
Date: Fri, 19 Apr 2019 12:33:38 +0200
Subject: [PATCH 12/17] Set vm.max_map_count to 262144 by default
The value is still pretty low, and AMD64-ABI and ELF extended numbering
supports that, so we should be fine on modern x86 systems.
This fixes crashes in some applications using more than 65535 vmas (also
affects some windows games running in wine, such as Star Citizen).
This is done here: