You are not logged in.
Hi all,
I am somewhat new to Arch Linux. I use vanilla Arch on my laptop, but on my gaming machine I use CachyOS. I want to move to vanilla Arch on my gaming machine as well, and I don't think this will be TOO difficult, but I'd like to discuss my methodology and what I have come up with so far. I have been using Linux for close to 20 years at this point, so I have some background, and I always prefer to be as close to a "Vanilla" distribution as I can. Debian over Ubuntu, etc. So that is where I'm coming from. Forgive me if this topic already exists elsewhere, I did try searching and could not find anything obvious.
For starters, I've only been using CachyOS for about 3 months, and I like it, but like I said, I like to be as close to vanilla as I can, because distributions come and go, but usually the main "core" distributions stick around. I also know I could just enable the CachyOS repos, but it goes back to what I'm saying about distributions coming and going, I've been burned before.
I figure the first step is making sure the multilib repository is enabled in /etc/pacman.conf (need this for Steam at least which I believe is 32-bit application)
Just uncomment this section in /etc/pacman.com:
[multilib]
Include = /etc/pacman.d/mirrorlistNext install the dependencies that it seems CachyOS has in its gaming meta package:
sudo pacman -S alsa-plugins giflib glfw gst-plugins-base-libs \
lib32-alsa-plugins lib32-giflib lib32-gst-plugins-base-libs \
lib32-gtk3 lib32-libjpeg-turbo lib32-libva lib32-mpg123 \
lib32-ocl-icd lib32-opencl-icd-loader lib32-openal \
libjpeg-turbo libva libxslt mpg123 opencl-icd-loader openalInstall the actual packages from the gaming meta package:
sudo pacman -S mangohud lib32-mangohud gamescope goverlay wine-staging winetricks protontricks vulkan-tools steam lutrisAnd Heroic launcher and ProtonUp-Qt from the AUR:
yay -S heroic-games-launcher-bin protonup-qtI have read that CachyOS applies a specific tweak for Split Lock Mitigation, without which there can be significant stuttering in some games, and to replicate this on vanilla Arch you would create a sysctl rule:
echo "kernel.split_lock_mitigate=0" | sudo tee /etc/sysctl.d/99-splitlock.conf
sudo sysctl --systemAnd also we'd need the Zen kernel:
sudo pacman -S linux-zen linux-zen-headersYou could go deeper with scheduler changes (scx-scheds), but possibly the ZEN Kernel would be enough by itself.
Does anyone have any strong feelings about this either way? Giant waste of time, or possibly workable?
DISCLAIMER: I have not actually done this on my gaming machine yet, at this point it's only a discussion and a little mental exercise I set for myself and would like to know what others think about it.
Offline
the main differences with CachyOS are actually their x86-64-v3/v4 optimized repositories and their custom kernels with the BORE scheduler, and installing linux-zen alone won’t really reproduce those aspects... and also worth noting that disabling split-lock mitigation can improve performance in some cases, but it’s generally something to mark as “use at your own risk” since it trades off a CPU safeguard.
If someone wanted the full CachyOS stack, enabling their repositories and using their kernel would probably be closer to the real thing, although that obviously moves away from the goal of staying fully vanilla.
---
Offline
Does "x86-64-v3/v4 optimized repositories" refer to applications that they've compiled with specific flags to be more efficient/faster? Yeah I guess that would be impossible to reproduce that in Arch.
I had not considered any security or other implications of disabling split-lock mitigation, but I guess it's right there in the name, mitigation.
Thanks for your reply.
Offline
Youre welcome, and yes, basically, CachyOS compiles many packages with more aggressive CPU targets and optimizations. Arch itself already uses an x86-64-v3 baseline now, but CachyOS goes further with things like additional compiler tuning, LTO, and sometimes x86-64-v4 builds for CPUs that support it, which allows the compiler to use newer vector instructions (AVX2, etc etc.), which can/might give measurable gains in some workloads... yeah you could reproduce something similar on vanilla Arch using https://wiki.archlinux.org/title/Arch_build_system and custom CFLAGS, but then you'd be rebuilding a lot of packages locally every time they update, at that point you're basically turning your system into a source based workflow similar to Gentoo Linux ![]()
As for split-lock mitigation: it prevents a class of instructions that can stall the memory bus, and disabling it can remove a bit of overhead in some situations, but it’s generally something you’d do knowingly, on shared systems it could theoretically be abused for a denial-of-service scenario, which is why the mitigation exists in the first place...
Edit:
striked out sh!t
Last edited by 5hridhyan (Today 09:07:18)
---
Offline
So it seems like, based on these replies, if I like the optimizations that CachyOS offers for my gaming machine then I'm probably better off just staying with CachyOS, or dealing with whatever limitations vanilla Arch has if I do feel the need to go fully vanilla. I've never run vanilla Arch on this machine, but maybe it's time to clone my current installation and just try it out, see how it does. Thanks again for your assistance here, you seem way more knowledgeable about this than I will likely ever be and I always appreciate input from those who know more than I do about any topic.
Offline
also worth noting that disabling split-lock mitigation can improve performance in some cases, but it’s generally something to mark as “use at your own risk” since it trades off a CPU safeguard.
Wouldn't this mitigate against someone who is also running software on your computer from DoSing whatever software you're running by abusing split locks? My understanding is that mitigating against split locks would only be relevant in cohosting since DoSing yourself doesn't sound like a problem for a single user system. Not only do you have permission to close the offending application(s), but it's up to you to start in the first place.
Offline
Actually, the security aspect is secondary for a desktop, the real issue is that the kernel (since 5.19) intentionally slows down processes that trigger split locks to "make life miserable" for the application in hopes developers will fix it, and like on a rig, if a game like God of War or Street Fighter 6 etc etc triggers a split lock, the kernel injects a 10ms delay, that’s what causes the hitching/stuttering, not a DoS from another user, && disabling the mitigation just stops the kernel from being a "nanny" and lets the hardware handle the bus lock normally, it's a "use at your own risk" mainly because a truly broken app could still theoretically stall your entire system, but for a single-user gaming machine, that's usually better than guaranteed micro-stutters... ![]()
---
Offline
Arch itself already uses an x86-64-v3 baseline now
Please explain further.
https://gitlab.archlinux.org/archlinux/ … kepkg.conf
sys2064
Offline
you're right to question that , Arch does not currently use an x86-64-v3 baseline, it still targets generic x86-64 for compatibility. I mixed that up with ongoing discussions and derivative repos like CachyOS/ALHP that do use v3/v4 targets... LoL I'm n00b
Last edited by 5hridhyan (Today 09:36:08)
---
Offline