{"id":167600,"date":"2026-05-17T16:47:27","date_gmt":"2026-05-17T13:47:27","guid":{"rendered":"https:\/\/computingforgeeks.com\/?p=167600"},"modified":"2026-05-18T07:06:05","modified_gmt":"2026-05-18T04:06:05","slug":"cachyos-kernel-manager-performance-tuning","status":"publish","type":"post","link":"https:\/\/computingforgeeks.com\/cachyos-kernel-manager-performance-tuning\/","title":{"rendered":"CachyOS Kernel Manager and Performance Tuning"},"content":{"rendered":"\n

CachyOS ships its own kernel, its own optimized package repos, and a small GUI called cachyos-kernel-manager<\/strong> for swapping between kernel variants. That stack is what separates CachyOS from every other Arch derivative, and it is the layer most worth understanding if you want CachyOS to actually outperform stock Arch on the same hardware. This guide covers what the CachyOS kernel changes, when to pick BORE over EEVDF over LTS, how to install and roll back kernels safely with Limine, and the small set of system-wide tunables (x86-64-v3 repos, ZRAM, BTRFS mount options) that make the most measurable difference.<\/p>\n\n\n\n

The article is laptop-flavoured because that is the audience most likely to care about scheduler choice for interactive responsiveness, but everything applies equally to a desktop or VM. All commands were tested end to end on a fresh CachyOS install with linux-cachyos, KDE Plasma, BTRFS, and Limine as the bootloader. If you have not done the basics yet, walk through things to do after installing CachyOS<\/a> first. Real captured output is inline.<\/p>\n\n\n\n

Tested May 2026 on the CachyOS 260426 desktop ISO with linux-cachyos 7.0.8 (EEVDF default), KDE Plasma on Wayland, and a BTRFS root using zstd compression. Test box: 4 vCPU host CPU passthrough, 16 GB RAM. Benchmarks ran inside a Proxmox VM, so absolute numbers do not translate to bare metal, but the verification commands are the same on any laptop.<\/em><\/p>\n\n\n\n

What the CachyOS kernel actually changes<\/h2>\n\n\n\n

Stock Arch ships linux<\/code>, the vanilla upstream kernel with Arch’s default config. CachyOS replaces it with linux-cachyos<\/code>, a kernel rebuilt from the same upstream tree but with three substantive differences:<\/p>\n\n\n\n

    \n
  • A different default scheduler.<\/strong> The current default linux-cachyos<\/code> uses EEVDF<\/strong> (Earliest Eligible Virtual Deadline First). EEVDF replaced CFS upstream in Linux 6.6 and is what mainline ships too; CachyOS just builds it with tuned defaults. Separate variants are available for BORE, BMQ, and other schedulers.<\/li>\n
  • Performance-oriented build flags.<\/strong> The package is GCC-compiled with Thin LTO. A separate linux-cachyos-lto<\/code> variant uses Clang Thin LTO with AutoFDO and Propeller profiling.<\/li>\n
  • Patches that have not landed upstream yet.<\/strong> Things like the BORE scheduler patches and various small performance tweaks live in CachyOS-PKGBUILDS and ride a few weeks ahead of mainline.<\/li>\n<\/ul>\n\n\n\n

    That is the whole story. The shipped kernel is mainline Linux with extra patches and tuned build flags. There is no fork, no proprietary code, no out-of-tree drivers you cannot find anywhere else. Confirm exactly which kernel is running and which CachyOS scheduler features are compiled in:<\/p>\n\n\n\n

    \"Terminal<\/figure>\n\n\n\n

    The kernel string ends in -cachyos<\/code> for the default, -cachyos-bore<\/code> for the BORE variant, -cachyos-lts<\/code> for the LTS series. CONFIG_SCHED_CLASS_EXT=y<\/code> means the kernel was built with sched_ext (the BPF scheduler framework) enabled, which is one of the CachyOS extras over a vanilla Arch build.<\/p>\n\n\n\n

    CachyOS kernel variants and when to pick which<\/h2>\n\n\n\n

    The CachyOS repo ships every variant of the kernel as a separate package. cachyos-kernel-manager<\/code> is just a GUI on top of pacman that installs, swaps, and removes them. The list as of this writing:<\/p>\n\n\n\n

    \n
    Package<\/th>Scheduler<\/th>When to pick it<\/th><\/tr><\/thead>
    linux-cachyos<\/code><\/td>EEVDF<\/td>The default. General-purpose desktop and developer use.<\/td><\/tr>\n
    linux-cachyos-bore<\/code><\/td>BORE<\/td>Interactive workloads and gaming. Favours I\/O-bound tasks that yield CPU often.<\/td><\/tr>\n
    linux-cachyos-eevdf<\/code><\/td>EEVDF<\/td>Explicit EEVDF build alongside the default. Use when you want EEVDF pinned in case the default changes.<\/td><\/tr>\n
    linux-cachyos-bmq<\/code><\/td>BMQ<\/td>BitMap Queue scheduler. Niche; pick only if a specific workload prefers it.<\/td><\/tr>\n
    linux-cachyos-rt-bore<\/code><\/td>BORE + PREEMPT_RT<\/td>Real-time workloads (pro audio, robotics control loops) that need bounded latency.<\/td><\/tr>\n
    linux-cachyos-lts<\/code><\/td>EEVDF<\/td>Long-term support kernel. Use as the fallback \/ second kernel when chasing kernel regressions.<\/td><\/tr>\n
    linux-cachyos-hardened<\/code><\/td>EEVDF<\/td>Security-focused kernel with linux-hardened patches applied.<\/td><\/tr>\n
    linux-cachyos-deckify<\/code><\/td>BORE<\/td>Steam Deck-style tuning and gaming hardware patches.<\/td><\/tr>\n
    linux-cachyos-server<\/code><\/td>EEVDF<\/td>Server-tuned config; longer timeslices, different IO defaults.<\/td><\/tr>\n
    linux-cachyos-lto<\/code><\/td>EEVDF<\/td>Clang Thin LTO build with AutoFDO + Propeller. The most aggressively optimised variant for raw throughput.<\/td><\/tr>\n<\/tbody><\/table><\/figure>\n\n\n\n

    The practical short answer for most laptop owners: stay on linux-cachyos<\/code> unless you have a specific reason to move. The reason will usually be one of: gaming responsiveness (try linux-cachyos-bore<\/code>), the default kernel has a regression on your hardware (move to linux-cachyos-lts<\/code> until upstream catches up), or you actually need real-time scheduling (linux-cachyos-rt-bore<\/code>).<\/p>\n\n\n\n

    What BORE does that EEVDF does not<\/h2>\n\n\n\n

    EEVDF is fair-by-design: tasks accumulate “lag” and the scheduler picks whoever has the earliest deadline among the eligible set. It is a clean, well-behaved scheduler that replaced CFS upstream.<\/p>\n\n\n\n

    BORE (Burst-Oriented Response Enhancer) sits on top of EEVDF and adds a “burstiness” score per task. A task that voluntarily yields the CPU often (waiting on I\/O, sleeping, blocking on the keyboard) accumulates a low burst score and gets scheduled preferentially. A task that burns CPU continuously gets a higher score and is penalised. The practical effect is that interactive workloads (typing into a terminal, scrolling a browser, the foreground game thread) feel more responsive while a parallel compile or AI inference run is in the background.<\/p>\n\n\n\n

    BORE exposes a handful of \/proc\/sys\/kernel\/<\/code> tunables that the daring can tweak (defaults shown). Note these only exist when running a BORE kernel; on a stock linux-cachyos<\/code> they will not appear in sysctl.<\/p>\n\n\n\n

    \n
    Sysctl<\/th>Default<\/th>Effect<\/th><\/tr><\/thead>
    kernel.sched_bore<\/code><\/td>1<\/td>Enable \/ disable BORE entirely<\/td><\/tr>\n
    kernel.sched_burst_penalty_offset<\/code><\/td>24<\/td>Threshold below which a task is treated as “short burst”<\/td><\/tr>\n
    kernel.sched_burst_penalty_scale<\/code><\/td>1536<\/td>How aggressively BORE discriminates against long-burst tasks<\/td><\/tr>\n
    kernel.sched_burst_smoothness<\/code><\/td>1<\/td>Smoothing factor on burst score transitions<\/td><\/tr>\n<\/tbody><\/table><\/figure>\n\n\n\n

    Leave the defaults alone unless you have a measurable workload that benefits from a change. The defaults are what the BORE author and the CachyOS team test against.<\/p>\n\n\n\n

    Use cachyos-kernel-manager to swap kernels safely<\/h2>\n\n\n\n

    cachyos-kernel-manager<\/code> is a Qt6 GUI that wraps pacman. It lists every CachyOS kernel package available in the repo, shows which are currently installed, and exposes install \/ remove buttons. Behind the scenes it runs pacman -S linux-cachyos-bore<\/code> (or similar) with polkit authentication. It does not build kernels from source. Launch it from the application menu or from a terminal:<\/p>\n\n\n\n

    cachyos-kernel-manager<\/code><\/pre>\n\n\n\n
    The kernel manager opens to a list of all available kernel packages with checkboxes for install:<\/p>\n\n\n\n
    \"cachyos-kernel-manager<\/figure>\n\n\n\n
    The pattern that actually works on a daily-driver laptop is to install at least two kernels and keep the second one as a known-good fallback. Best pairing: the default linux-cachyos<\/code> plus linux-cachyos-lts<\/code>. Switch to the LTS entry from the bootloader whenever a kernel update breaks something, file an upstream bug, and switch back when the regression is fixed.<\/p>\n\n\n\n
    You can install kernels straight from the terminal too, which is faster than walking the GUI when you already know which one you want:<\/p>\n\n\n\n
    sudo pacman -S linux-cachyos-bore linux-cachyos-bore-headers\nsudo pacman -S linux-cachyos-lts linux-cachyos-lts-headers<\/code><\/pre>\n\n\n\n
    On Limine (the CachyOS default bootloader), the install hook auto-regenerates the bootloader entries and adds the new kernel to \/boot\/limine.conf<\/code>. No grub-mkconfig<\/code> step is needed. On the GRUB variant of the install, regenerate with sudo grub-mkconfig -o \/boot\/grub\/grub.cfg<\/code> after every kernel install.<\/p>\n\n\n\n
    The Limine boot menu with multiple kernels<\/h2>\n\n\n\n
    After installing a second and third kernel, the Limine menu on the next boot lists all of them under the CachyOS<\/code> entry. Press a key during the 5-second countdown to stop the auto-boot, arrow up or down to pick a kernel, and press Enter:<\/p>\n\n\n\n
    \"Limine<\/figure>\n\n\n\n
    The [+] Snapshots<\/code> submenu is the snapper integration. CachyOS ships limine-snapper-sync<\/code>, which adds every BTRFS snapshot snapper takes as a bootable entry. When a pacman update breaks the system, you reboot, pick a pre-update snapshot from the Snapshots submenu, and you are back in a working state in under thirty seconds. That side of the workflow is the topic of a separate Day-2 guide on BTRFS snapshots and rollback.<\/p>\n\n\n\n
    Confirm the x86-64-v3 optimised repos are enabled<\/h2>\n\n\n\n
    CachyOS ships parallel package repos compiled for the x86-64-v3<\/strong> microarchitecture level (roughly Haswell and newer, ~2013+) and x86-64-v4<\/strong> (AVX-512 era CPUs). On supported hardware, the installer enables the v3 repo automatically. Verify with:<\/p>\n\n\n\n
    \/lib\/ld-linux-x86-64.so.2 --help | grep -A2 \"supported, searched\"\ngrep -E '^\\[' \/etc\/pacman.conf\nls \/etc\/pacman.d\/cachyos-*mirrorlist<\/code><\/pre>\n\n\n\n
    On a v3-eligible CPU the dynamic linker and pacman repos look like this:<\/p>\n\n\n\n
    \"Terminal<\/figure>\n\n\n\n
    If you see [cachyos-v3]<\/code>, [cachyos-extra-v3]<\/code>, and [cachyos-core-v3]<\/code> in pacman.conf<\/code>, the v3 repos are wired up: pacman pulls v3-compiled packages where they exist and falls back to the plain [cachyos]<\/code> repo otherwise. The v4 mirrorlist file exists too but is only used if your CPU advertises AVX-512.<\/p>\n\n\n\n
    If your CPU is v3-capable but you only see the plain [cachyos]<\/code> repo, the installer missed it. Enable v3 manually:<\/p>\n\n\n\n
    sudo pacman -S --noconfirm cachyos-v3-mirrorlist<\/code><\/pre>\n\n\n\n
    Then add the v3 repo entries to \/etc\/pacman.conf<\/code> above the plain cachyos repo so it wins resolution. Run sudo pacman -Syu<\/code> and pacman will replace any v1-built package with its v3 sibling where one exists. The benefit varies by workload. Codec-heavy and crypto-heavy paths see the largest wins; most desktop apps see single-digit percent improvements.<\/p>\n\n\n\n
    ZRAM is already configured<\/h2>\n\n\n\n
    CachyOS enables ZRAM by default via systemd-zram-generator<\/code>. ZRAM is a compressed in-memory swap device; on a laptop with 8-16 GB of RAM it lets you push past memory pressure without touching the SSD. Confirm it is running:<\/p>\n\n\n\n
    zramctl\nswapon --show\nsysctl vm.swappiness vm.page-cluster<\/code><\/pre>\n\n\n\n
    On a clean CachyOS install you should see ZRAM, swap, and the swappiness sysctl already set:<\/p>\n\n\n\n
    \"zramctl<\/figure>\n\n\n\n
    The default config uses zstd<\/code> compression and sizes ZRAM to half of RAM (15.6 G on this 16 GB test box). cachyos-settings<\/code> pairs that with vm.swappiness=150<\/code>, which sounds extreme but is correct for ZRAM-only swap: you want the kernel to prefer compressed RAM over evicting page cache. vm.page-cluster=0<\/code> means single-page reads from swap (good for ZRAM, bad for spinning disks).<\/p>\n\n\n\n
    You can keep ZRAM as the only swap on a laptop with at least 8 GB of RAM. If you also want suspend-to-disk, add a small swap file or swap partition for hibernation only. ZRAM cannot resume from suspend-to-disk because the compressed pages live in volatile memory.<\/p>\n\n\n\n
    BTRFS mount options that matter<\/h2>\n\n\n\n
    The Calamares “Erase disk \u2192 btrfs” path lays out subvolumes that snapper and grub-btrfs\/limine-snapper-sync expect, with sensible mount options preset in \/etc\/fstab<\/code>. Look at the actual mount lines:<\/p>\n\n\n\n
    findmnt -t btrfs\ngrep btrfs \/etc\/fstab<\/code><\/pre>\n\n\n\n
    The mounted subvolume layout on a fresh BTRFS install looks like this:<\/p>\n\n\n\n
    \"findmnt<\/figure>\n\n\n\n
    The defaults are noatime<\/code>, compress=zstd:3<\/code>, space_cache=v2<\/code>, discard=async<\/code>, ssd<\/code>, and per-subvolume subvol=<\/code> entries. That is already the production-ready mount set for an SSD-backed laptop, and it gives snapper the @-prefixed subvolume layout it expects. Notes on each option:<\/p>\n\n\n\n