CachyOS: Performance Arch Linux With BORE Kernel and Graphical Installer

Arch Linux ships generic x86-64-v1 binaries that run on hardware from 2003. CachyOS ships binaries compiled for the CPU you actually have. That single design decision cascades into everything else the project does: a custom kernel built with profile-guided optimization, scheduler patches tuned for desktop responsiveness, and a repository of Arch packages rebuilt with AVX2 or AVX-512 instruction sets depending on what your hardware supports. If you have spent time on a stock Arch install wondering whether the system is leaving performance on the table, CachyOS is the answer to that question.

This guide covers the technical substance of what CachyOS changes, why those changes matter at the kernel and compiler level, and how to work with the tooling it provides -- from kernel variant selection to live sched-ext scheduler switching after install.

What CachyOS Actually Is

CachyOS is a rolling-release Arch Linux derivative first released in 2021 and actively maintained by Peter Jung (ptr1337) and Vladislav Nepogodin (vnepogodin). Its core premise is that the Linux performance stack contains substantial untapped headroom when you compile for specific hardware rather than generic compatibility targets.

The project operates three primary levers to extract that headroom. First, it rebuilds Arch packages against x86-64-v3, x86-64-v4, and AMD Znver4 microarchitecture profiles, enabling instruction set paths that mainstream distributions never emit. Second, it ships custom kernel variants led by the default linux-cachyos -- which runs BORE scheduling and receives AutoFDO+Propeller profile-guided optimization since February 2025 -- alongside a range of specialist variants for LTO, real-time, server, and handheld use. Third, it provides a hardware detection tool (chwd, written in Rust) that selects the appropriate driver profiles and package tiers automatically during installation.

Microarchitecture Tiers and What They Mean

The x86-64 microarchitecture levels were formalized by the systemd project as a practical way to tier binary compatibility. The relevant levels for CachyOS are:

• x86-64-v1 -- the baseline, targeting the original AMD64/EM64T feature set. All mainstream Linux distributions default here.
• x86-64-v3 -- requires AVX, AVX2, BMI1, BMI2, FMA, MOVBE, XSAVE, and several other extensions. Covers most CPUs manufactured after 2015, including Intel Haswell and AMD Excavator onward.
• x86-64-v4 -- additionally requires AVX-512. Available on Intel Skylake-X, Ice Lake, and later; AMD Zen 4 and later.

When CachyOS compiles a package against v3, the compiler can emit 256-bit AVX2 vector operations instead of falling back to 128-bit SSE paths. For workloads that spend significant time in SIMD-heavy code -- media processing, compression, cryptography, scientific computation -- the difference in throughput is real. For workloads that are entirely I/O-bound or memory-bandwidth-limited, the gains are negligible.

Core packages receive additional optimization passes on top of the microarchitecture flags. Link Time Optimization (LTO) allows the compiler to reason across translation unit boundaries during linking, enabling inlining and dead code elimination that per-file compilation cannot perform. Some packages additionally receive Profile-Guided Optimization (PGO) and BOLT post-link optimization, which reorder code to improve instruction cache locality based on measured execution patterns.

The Kernel Variants

CachyOS ships a fleet of kernel variants, each targeting a different workload profile. Understanding what distinguishes them lets you make an informed choice at install time rather than accepting defaults blindly.

The variant lineup as of early 2026 is as follows:

Since the August 2025 release, the installer automatically adds linux-cachyos-lts as a fallback kernel alongside whichever variant you choose as primary. The live ISO ships with both a stable and an LTS kernel, with the stable kernel as the default boot option as of January 2026. The linux-cachyos-mainline variant, based on Linus's mainline tree, is available for users who want the absolute latest upstream changes alongside the CachyOS patchset; the CachyOS wiki describes it as the kernel used to introduce new features to the patchset before they move to the stable variants.

What is linux-cachyos-bmq and who is it for?

The BMQ (BitMap Queue) scheduler is the work of developer Alfred Chen, shipped as part of his Project C patchset. It is a departure from the EEVDF lineage entirely: instead of using deadline-based virtual time accounting like EEVDF and BORE, BMQ assigns tasks to priority bitmap queues and schedules by picking the highest-priority non-empty queue. The design prioritizes extreme low overhead in the scheduling fast path, which can benefit workloads dominated by many short-lived tasks that would otherwise generate high scheduler churn.

In practice, BMQ tends to perform well under certain highly parallel workloads but produces less consistent interactive response than BORE on mixed desktops. It has a narrower use case than the default kernel and exists in the CachyOS lineup primarily for users who have tested it against their specific workload and found it favorable. Two practical constraints: it does not support sched-ext (so you cannot layer BPF schedulers on top of it), and it does not receive the AutoFDO+Propeller profiling passes that the default kernel does. For most users evaluating CachyOS, the default linux-cachyos or linux-cachyos-bore is the better starting point.

What does linux-cachyos-hardened actually harden?

linux-cachyos-hardened applies the linux-hardened patchset maintained by Arch developer anthraxx, on top of the CachyOS base patchset. The hardening suite activates a range of kernel security mitigations that the upstream kernel ships as optional or disabled by default: stricter module signing requirements, randomized kernel stack offsets at syscall boundaries, reduced kernel pointer exposure in /proc and /sys, and tighter restrictions on unprivileged user namespaces and BPF.

The cost is real. Some of these mitigations add measurable overhead on paths that run frequently -- syscall-heavy workloads, container runtimes, and anything that exercises BPF heavily will see degraded performance compared to the standard kernel. The wiki describes the performance impact as significant. The absence of sched-ext support is a direct consequence of the hardened BPF restrictions: the same kernel configuration that tightens unprivileged BPF access also prevents loading the BPF-based sched-ext schedulers.

This variant is the right choice if you are running CachyOS in a security-sensitive context -- a developer workstation that handles secrets, a machine exposed to untrusted workloads, or a system where reducing kernel attack surface is worth the performance tradeoff. It is not the right choice for gaming or general desktop use where you want sched-ext or maximum throughput.

One clarification that cuts through a common misconception: the default linux-cachyos kernel does use BORE. The CachyOS kernel wiki confirms this: the default kernel runs BORE on top of EEVDF, with CONFIG_CACHY tunables applied for improved desktop responsiveness. BORE is also present on linux-cachyos-bore, linux-cachyos-lts, linux-cachyos-rt-bore, linux-cachyos-deckify, linux-cachyos-mainline, and linux-cachyos-hardened. The variants that do not use BORE are linux-cachyos-server (which uses stock EEVDF for throughput-oriented server workloads), linux-cachyos-bmq (which uses the BMQ scheduler from Project C), and linux-cachyos-eevdf (which runs tuned EEVDF with CONFIG_CACHY settings but without the BORE burstiness layer). If you have been running the default linux-cachyos kernel thinking you were on plain EEVDF, you have been running BORE all along.

What is linux-cachyos-eevdf and when would you use it?

linux-cachyos-eevdf runs the stock upstream EEVDF scheduler with the full CachyOS base patchset (CONFIG_CACHY tunables, aes-crypto patches, BBRv3, 1000 Hz timer frequency) applied, but without the BORE burstiness layer on top. It is not a stripped-down variant -- everything in Cachy Sauce is present. The single difference from the default linux-cachyos is that the per-task burstiness score tracking and BORE's wakeup preemption adjustments are absent. The kernel uses EEVDF's own latency-based scheduling decisions without any additional interactivity weighting.

The practical question is when this matters. BORE's burstiness scoring is designed to make mixed desktop workloads feel more responsive by promoting tasks that yield the CPU frequently. On workloads where every task is already CPU-bound and running continuously -- rendering, compilation, machine learning inference -- BORE's interactivity weighting adds overhead without providing any scheduling benefit, since no task behaves like an interactive application. In those scenarios, linux-cachyos-eevdf gives you EEVDF's fair scheduling with lower scheduling overhead than BORE introduces. It supports sched-ext, so BPF schedulers can still be loaded on top of it if needed.

What is linux-cachyos-deckify and which hardware is it for?

linux-cachyos-deckify is the default kernel for CachyOS's Handheld Edition, which officially supports the Steam Deck (LCD and OLED), ROG Ally, Legion Go, and Legion Go S. It carries the BORE scheduler and the full CachyOS base patchset, plus a layer of handheld-specific patches on top. Those patches address device-specific concerns that do not apply to desktop hardware: suspend and resume reliability on handheld APUs, power button handling, TDP control integration, screen orientation, and compatibility with controller input systems like InputPlumber and Handheld Daemon (HHD).

The Handheld Edition pairs this kernel with a SteamOS-like Game Mode experience built on gamescope-session-cachyos, which forks Valve's gamescope-session and adds firmware update support for Steam Deck and Legion Go devices. The CachyOS wiki explicitly states that linux-cachyos-deckify is not recommended or supported on non-handheld hardware -- the patches it carries are device-specific enough that running it on a desktop or laptop provides no benefit and may cause unexpected behavior.

For scheduler configuration on handheld hardware, the recommended sched-ext scheduler is scx_lavd (Latency-criticality Aware Virtual Deadline) rather than the default scx_bpfland. LAVD was developed with Valve's involvement and is specifically tuned for the mixed workload profile of handheld gaming -- alternating between burst GPU loads and periods of relative idle -- improving frame time consistency and 1% lows compared to schedulers designed for desktop throughput profiles. The Handheld Edition ships with this configuration pre-applied.

The BORE Scheduler: How It Works

EEVDF (Earliest Eligible Virtual Deadline First) replaced the older CFS scheduler in Linux 6.6 and improved fairness accounting. BORE builds on top of EEVDF rather than replacing it.

The central concept BORE introduces is a per-task burstiness score. The scheduler tracks how much CPU time each task has consumed since it last voluntarily yielded -- either by going to sleep, waiting for I/O, or explicitly calling sched_yield(). This accumulated consumption is the burst time. BORE calculates a burst score from this value using a logarithmic scaling function, producing a number between 0 and 39 that functions analogously to niceness.

Tasks with low burstiness scores -- those that frequently yield the CPU -- receive more aggressive wakeup preemption and longer timeslices when they become runnable. Tasks with high burstiness scores are weighted down. This means interactive applications like terminals, editors, and UI compositors, which spend time blocked on input and wake up to do short bursts of work, are promoted over CPU-hungry background processes that hold the scheduler continuously.

The effect is not about raw throughput. It is about latency distribution -- reducing the tail latency of interactive tasks under load, which is what makes a desktop feel responsive even when the system is under heavy CPU pressure.

The burstiness score adapts over time. A task that becomes greedy after previously being interactive will see its score increase and its scheduling priority decrease. This prevents transient behavior from permanently miscategorizing a task.

Looking at the actual patch makes the implementation concrete. BORE adds a bore_ctx struct to every task_struct, containing burst_time (a u64 nanosecond counter), two penalty fields tracking the previous and current penalty across yield boundaries, a score byte derived from those penalties, and two boolean flags: stop_update (prevents reweighting races) and futex_waiting. That last flag is a detail worth understanding: BORE sets futex_waiting = true while a task is blocked inside futex_do_wait(), which prevents burst time from accumulating during mutex and semaphore contention. A task waiting on a lock is not being greedy -- it is blocked -- and BORE does not penalize it for that wait time. The entire BORE logic lives in a dedicated 428-line file (kernel/sched/bore.c) compiled only when CONFIG_SCHED_BORE=y.

BORE also introduces MIN_BASE_SLICE_NS, defaulting to 2,000,000 ns (2 ms). At 1000 Hz, the scheduler tick period is 1 ms; without this floor, BORE's timeslice calculations under heavy load could produce sub-millisecond slices that hurt throughput through excessive context switching. The floor prevents that while keeping latency low.

All key BORE parameters are writable at runtime via /proc/sys/kernel/. The main tunables are sched_bore (0 or 1, enables/disables the feature entirely), sched_burst_penalty_offset (default 24, range 0–63; controls where burst scoring starts -- lower values penalize shorter bursts more aggressively), sched_burst_penalty_scale (default 1536, range 0–4095; scales how steeply the penalty grows with burst time), sched_burst_cache_lifetime (default 75,000,000 ns; how long a completed burst's score persists before decaying), and sched_burst_smoothness (default 1; controls how quickly the score changes between update cycles). CachyOS ships these at their upstream defaults. Users who want to tune interactivity vs. throughput tradeoffs can adjust them without rebuilding the kernel:

# View current BORE settings
$ sysctl kernel.sched_bore kernel.sched_burst_penalty_offset kernel.sched_burst_penalty_scale kernel.sched_burst_cache_lifetime kernel.sched_burst_smoothness

# Increase penalty aggressiveness (lower offset = penalize bursts sooner)
$ sudo sysctl -w kernel.sched_burst_penalty_offset=16

# Persist across reboots via sysctl.d
$ echo "kernel.sched_burst_penalty_offset=16" | sudo tee /etc/sysctl.d/99-bore-tuning.conf

"For users who need maximum interactivity, our kernels support the BORE scheduler, a patch set that enhances EEVDF to deliver a more fluid experience during intensive workloads." -- CachyOS Wiki, Why CachyOS?

The CachyOS Base Patchset: CONFIG_CACHY

Every kernel variant in the CachyOS lineup -- including the default linux-cachyos -- ships with the CachyOS Base Patchset, informally called the "Cachy Sauce." This is a set of kernel configuration changes and patches applied on top of whatever scheduler or optimization tier the variant uses, and it is the foundation that distinguishes all CachyOS kernels from a plain Arch Linux build.

"CachyOS Sauce: Custom CONFIG_CACHY configuration with scheduler and system tweaks." -- CachyOS/linux-cachyos on GitHub

The base patchset covers several categories. The aes-crypto patches provide dramatically improved throughput for encryption workloads by dynamically selecting between AVX2, AVX-512, and AVX10.1 instruction paths depending on what the CPU supports at runtime. The amd-pstate patches incorporate improvements to AMD's P-state power management driver from the upstream mailing list before they reach stable kernel releases, along with AMD Preferred Core support. The bbr3 patch replaces BBRv2 with Google's BBRv3 TCP congestion control algorithm. The block patches improve the BFQ and mq-deadline I/O scheduler implementations.

The cachy patches themselves adjust CONFIG_CACHY -- a custom kernel config symbol -- along with related tunables for scheduler interactivity, preemption behavior, transparent hugepage settings, and timer resolution. All CachyOS kernels default to a 1000 Hz timer frequency rather than the upstream 250 Hz default. This higher tick rate reduces scheduling latency at the cost of slightly more timer interrupt overhead, a tradeoff that consistently benefits interactive desktop use but is why the linux-cachyos-server variant drops back to a lower frequency.

AutoFDO and Propeller: Profile-Guided Kernel Builds

AutoFDO (Automatic Feedback-Directed Optimization) is a technique developed at Google that uses runtime execution profiles to guide compiler optimization decisions. Instead of the compiler making static inferences about hot code paths, it incorporates empirical data collected from actual workloads.

Building an AutoFDO-optimized kernel involves three steps. First, the kernel is built with profiling instrumentation enabled. Second, representative workloads are executed and hardware performance counter data is collected using perf. Third, the kernel is rebuilt with that profile data provided to the compiler, which uses it to make better inlining, branch prediction, and code layout decisions for the paths that actually matter under real-world load.

CachyOS maintains its own AutoFDO profile for its kernels, generated by running a suite of workloads representative of desktop and development use. As of the December 2024 release, the default kernel first shipped with AutoFDO applied; as of the February 2025 release, Propeller was added to the default GCC kernel once LLVM 19 landed. The profiling workload set runs on a Zen 5 machine and includes sysbench CPU tests, the CachyOS Benchmarker suite, Git operations, kernel compilation, and miscellaneous benchmarks. The raw branch sampling data is collected with perf record --pfm-events RETIRED_TAKEN_BRANCH_INSTRUCTIONS:k on AMD and BR_INST_RETIRED.NEAR_TAKEN:k on Intel, using a sample period of 500,009 (a prime to reduce aliasing). This produces approximately 1.4 GB of raw perf data, which is then converted to an AutoFDO profile using create_llvm_prof before being fed back into the compiler for the final kernel build.

An important hardware constraint: AutoFDO and Propeller require CPUs with Last Branch Record (LBR) support to collect the branch sampling data. On AMD this means Zen 3 EPYC with BRS support, Zen 4, or Zen 5. On Intel it means Haswell and later. The profile CachyOS generates on its Zen 5 build machine is cross-architecture compatible -- the relative line number matching AutoFDO uses means an AMD-generated profile can produce improvements on Intel hardware too -- but CPUs that cannot collect LBR data cannot be used to generate profiles themselves. The linux-cachyos-lto Clang/ThinLTO variant also receives both AutoFDO and Propeller profiling. According to the CachyOS project, combining these two optimization techniques yields approximately 10% throughput improvement and reduced latency compared to a non-profiled build, depending on the workload.

The profiling script CachyOS uses is publicly available at github.com/CachyOS/cachyos-benchmarker. The project invites community contributions to expand workload coverage. For users who want to generate a custom profile against their own workloads, CachyOS publishes a detailed guide at cachyos.org/blog/2411-kernel-autofdo.

Propeller extends AutoFDO with an additional optimization step focused on code layout. Where AutoFDO primarily informs inlining and optimization decisions, Propeller reorganizes the binary layout of hot functions to improve instruction cache utilization and reduce branch mispredictions from cold paths being interleaved with hot ones. Both AutoFDO and Propeller are applied to the default linux-cachyos kernel and the linux-cachyos-lto Clang variant.

"In general, combining these two optimization techniques should result in approximately a 10% throughput improvement (depending on the workload) as well as latency improvements." -- CachyOS February 2025 Release Notes

The sched-ext Framework

sched-ext (SCX, Extensible Scheduler Class) is a Linux kernel feature that landed in mainline with 6.12. It allows kernel thread schedulers to be implemented as BPF programs and loaded dynamically from userspace -- no kernel rebuild required to switch scheduling algorithms.

CachyOS has first-class support for sched-ext on all kernel variants except linux-cachyos-bmq and linux-cachyos-hardened. The scx-scheds package provides the scheduler binaries. As of scx version 1.0.18, scx_loader and scxctl were moved to a separate scx-tools package; install both together with sudo pacman -S scx-scheds scx-tools. The available schedulers include:

• scx_bpfland -- a vruntime-based scheduler that tracks per-task wakeup patterns to determine interactivity. Its core mechanism is a hierarchical three-tier DSQ structure: per-CPU queues, per-node queues (for NUMA-aware dispatch), and a shared fallback queue. Tasks with an average runtime under 10 microseconds are classified as "sticky" and dispatched directly to SCX_DSQ_LOCAL, bypassing the shared queue entirely to avoid lock contention -- this is why kernel threads and short-lived tasks are handled more efficiently than in naive schedulers. The scheduler respects L2/L3 cache topology when selecting idle CPUs, producing fewer cache misses than topology-blind alternatives. A good general-purpose choice with Gaming and Powersave profiles.
• scx_lavd -- Latency-criticality Aware Virtual Deadline. A task's virtual deadline is inversely proportional to its measured latency criticality: a task with twice the latency criticality gets a deadline delta twice as small, placing it earlier in the scheduling queue. LAVD implements Core Compaction: when system CPU utilization falls below 50%, it consolidates workload onto fewer cores running at higher frequency while allowing idle cores to enter deep C-states, improving both per-task throughput and power consumption simultaneously. Compositors (KWin, GNOME Shell, Hyprland, Sway) are automatically identified and boosted to LAT_CRITICAL tier. Targets gaming and interactive workloads; the recommended choice for handheld hardware.
• scx_p2dq -- a behavioral classification scheduler that uses EWMA-driven scoring (wakeup frequency, context switch rate, runtime variance) to sort tasks into three dispatch tiers: LAT_CRITICAL, INTERACTIVE, and BATCH, each with its own timeslice, preemption rules, and DSQ routing. A CoDel-inspired sojourn rescue mechanism tracks batch queue wait times and rescues aging tasks before they stall. A persistent process database learns task classifications across reboots. Replaces the old scx_bpfland lowlatency mode.
• scx_rusty -- multi-domain scheduler with NUMA awareness and load balancing. Suited to machines with many cores or multiple NUMA nodes; also the recommended option for general-purpose server workloads.

Schedulers are managed through scx_loader, which uses a D-Bus interface. Configuration persists in /etc/scx_loader.toml and survives reboots. As of the March 2025 release, the sched-ext GUI was split out of the CachyOS Kernel Manager into a standalone application called scx-manager. The Kernel Manager still provides a sched-ext tab as a pass-through, but scx-manager is now the dedicated standalone tool. scxctl is the command-line client; it is provided by the scx-tools package (split from scx-scheds as of scx version 1.0.18). The key subcommands are start (launch a scheduler with -s for scheduler name and -m for mode), switch (change scheduler or mode without stopping), get (show currently running scheduler and mode), and stop. Valid modes are auto, gaming, powersave, lowlatency, and server:

# Install scheduler suite and scxctl/scx_loader (scx-tools split as of v1.0.18)
$ sudo pacman -S scx-scheds scx-tools

# Check currently active scheduler and mode
$ scxctl get

# Start scx_bpfland in gaming mode
$ sudo scxctl start -s scx_bpfland -m gaming

# Check the currently running scheduler and mode
$ scxctl get

# Switch mode without restarting (e.g. to powersave)
$ sudo scxctl switch -m powersave

# Stop the sched-ext scheduler (reverts to kernel BORE/EEVDF)
$ sudo scxctl stop

# Enable persistence -- chosen scheduler loads on every boot
$ sudo systemctl enable --now scx_loader

The persistence configuration in /etc/scx_loader.toml records both the chosen scheduler name and mode, so the system boots directly into your preferred scheduling configuration without manual intervention. Mode values in the TOML file use Title Case ("Auto", "Gaming", "Powersave", "Lowlatency", "Server"); the CLI flags use lowercase.

# /etc/scx_loader.toml -- loads scx_bpfland in gaming mode on boot
default_sched = "scx_bpfland"
default_mode = "Gaming"

# Optional: per-scheduler mode flag overrides
# [scheds.'scx_bpfland']
# gaming_mode = []
# powersave_mode = []

Proton-CachyOS and Gaming Optimizations

CachyOS ships its own Proton fork, Proton-CachyOS, which diverges from Valve's upstream in several areas relevant to gaming on Linux:

• NTSync -- an alternative kernel-based synchronization mechanism for Wine that reduces per-synchronization-object overhead compared to esync and fsync. Enabled by default in Wine and Wine-Staging on CachyOS as of the 2025 year-end release.
• WoW64 mode -- allows running 32-bit Windows applications without installing the full set of 32-bit lib32 libraries on the host system. Also default since late 2025.
• Shader caching per game -- reduces stutter after initial shader compilation by storing caches on a per-game basis rather than in a shared location.
• FSR 4 on RDNA3 -- AMD's upscaling technology exposed through the Proton layer for RDNA3 GPUs.
• DLSS and XeSS upgraders -- allow using newer DLSS and Intel XeSS libraries than what a game ships with, provided the newer version is backward-compatible.

For NVIDIA users, CachyOS defaults to the open-source NVIDIA kernel modules for Turing (RTX 20xx) and newer GPUs, tracking NVIDIA's own trajectory toward open-source kernel-level drivers. If you want the full picture on how those modules work, see NVIDIA Linux drivers: open modules, GSP firmware, and the road to Blackwell. Precompiled modules are bundled in the kernel package, eliminating DKMS rebuilds on kernel updates. Both open and proprietary module variants are precompiled and available in the repository.

How to Install CachyOS and Configure the Performance Kernel

CachyOS uses a modified Calamares graphical installer. The installation flow presents choices that most distributions do not expose at install time: desktop environment, filesystem, bootloader, kernel variant, and whether to enable the optimized repository tiers.

The hardware detection tool chwd runs early in the process and identifies your CPU architecture tier and GPU vendor, then configures the appropriate repository and driver profiles automatically. The installer supports both online and offline modes; the offline ISO installs KDE Plasma with a default package set, while the online installer fetches the current package state and offers the full DE selection including GNOME, Hyprland, Niri, Sway, COSMIC, and seventeen other options.

As of January 2026, the ISO boots with both a stable kernel and an LTS kernel, with the stable kernel selected by default. The live environment has switched from X11 to Wayland by default, and SDDM has been replaced by Plasma Login Manager. Limine is now the default bootloader, replacing GRUB as the default; GRUB remains available as an alternative. Architecture detection now runs at the start of installation, reducing download sizes by roughly 1 GB by fetching only packages relevant to your CPU tier.

This shows the hardware profiles that chwd has detected as applicable to your system's PCI devices -- your GPU, network card, and any other supported hardware. It does not list every profile in the database; use sudo chwd --list-all for that. For systems where chwd did not apply the right profile automatically, you can install one manually:

# List all available hardware profiles
$ sudo chwd --list-all

# Install a specific profile
$ sudo chwd -i pci nvidia-open-dkms

# Show installed profiles
$ chwd --list-installed

After booting into the installed system, cachyos-hello launches automatically and provides links to post-install configuration options: applying gamer package sets, switching to a different kernel via the Kernel Manager, enabling the optimized mirrors via cachyos-rate-mirrors, and configuring Btrfs snapshots if the installer set up the filesystem that way.

The cachyos-settings package, installed by default, applies a set of system-wide optimizations via udev rules and sysctl that most users never inspect but that have measurable effect. On the I/O side, it assigns I/O schedulers by device type: BFQ for HDDs, mq-deadline for SATA SSDs, and none (no scheduler, direct pass-through to the NVMe hardware queue) for NVMe drives. The kernel's default of mq-deadline for all blk-mq devices is not optimal for NVMe, where a software scheduler only adds overhead. On the memory side, it sets vm.swappiness=150 specifically for ZRAM swap (preferring anonymous page compression in RAM over eviction to disk), disables Zswap to prevent double compression, and adjusts dirty page parameters -- for a thorough look at what these Linux kernel tuning parameters do under load, that guide covers the full sysctl surface. For NVIDIA users, the package also installs modprobe configuration that sets NVreg_UsePageAttributeTable=1 (enables PAT for CPU cache performance), NVreg_InitializeSystemMemoryAllocations=0 (skips NVIDIA's zeroing of system memory allocations at driver load, saving startup latency), NVreg_DynamicPowerManagement=0x02 (enables runtime D3 power management for mobile GPUs), and NVreg_RegistryDwords=RMIntrLockingMode=1 (improves frame pacing under interrupt load). Users adding the CachyOS repos to an existing Arch install do not get these settings automatically -- they need to explicitly install cachyos-settings.

Btrfs with zstd compression is the recommended default and what the installer selects unless you override it. Both Limine and GRUB installations on Btrfs automatically configure bootable snapshots, so you can roll back a broken kernel update or package state from the boot menu without a live ISO. Limine became the default bootloader as of January 2026; users already running GRUB can optionally migrate to Limine, but no action is required for existing installations.

The installer also supports ext4, XFS, and F2FS as alternative filesystem selections. ext4 and XFS are mature choices for users who want simpler, well-understood filesystems without the snapshot layer. F2FS is available primarily for flash-native storage scenarios. Bcachefs was available as an experimental option in earlier releases but was removed from the installer as of March 2026 following stability concerns; the March 2026 release notes confirm its removal. Existing installations on Bcachefs are not affected by this change.

The Kernel Manager

CachyOS ships a graphical kernel manager that handles three distinct functions: installing kernels from the repository, building custom kernels locally with a configuration GUI, and managing the sched-ext framework.

The repository installation tab lists all available linux-cachyos-* variants and lets you install or remove them alongside the running kernel. Because CachyOS precompiles all kernel modules (including NVIDIA and ZFS) for each variant, switching between variants does not require waiting for DKMS to rebuild anything -- it is a normal package install.

The custom build tab exposes PKGBUILD-level configuration through a GUI: scheduler selection, timer frequency (300 Hz, 500 Hz, 600 Hz, 750 Hz, or 1000 Hz), compiler choice (GCC or Clang), LTO toggles, and CPU microarchitecture target. Built kernels are cached in ~/.cache/cachyos-km/ and can be reinstalled without a full rebuild.

The sched-ext tab communicates with scx_loader over D-Bus to switch between available schedulers and profiles. This is the same functionality as the scxctl command line tool, surfaced in a GUI for systems where you prefer not to memorize the scxctl invocations.

The packages.cachyos.org Dashboard

Since the August 2025 release, CachyOS operates a public package dashboard at packages.cachyos.org. Each package entry shows whether it originates directly from Arch, has been modified by CachyOS, or comes from the AUR. The PKGBUILD source is linked directly, and binary downloads are available for manual inspection or offline installation.

This transparency layer is practically useful when debugging. If a package is behaving unexpectedly, you can immediately determine whether CachyOS has applied patches to it and what those patches contain. It also provides a clear answer to a common question from users evaluating whether to switch: you can audit exactly which packages in the stack have been rebuilt versus pulled unchanged from Arch.

Adding CachyOS to an Existing Arch Install

A full fresh install is not required. CachyOS publishes a repository that can be layered onto a running Arch system, giving you the optimized package tiers and the CachyOS kernels without reinstalling. The process involves adding the CachyOS keyring and mirrorlist packages, then adding the appropriate repository stanzas to /etc/pacman.conf.

# Download and run the automated repo installer
$ curl -O https://mirror.cachyos.org/cachyos-repo.tar.xz
$ tar xvf cachyos-repo.tar.xz && cd cachyos-repo
$ sudo ./cachyos-repo.sh

# After adding repos, install the CachyOS default kernel
$ sudo pacman -S linux-cachyos linux-cachyos-headers

# Verify the correct architecture tier was detected
$ grep cachyos /etc/pacman.conf

The installer script detects your CPU microarchitecture tier and adds the appropriate stanzas ([cachyos-v3], [cachyos-v4], or [cachyos-znver4]) above the standard [core] and [extra] repos. Packages with CachyOS-rebuilt versions will be preferred on the next pacman -Syu.

One important caveat: CachyOS ships a forked version of pacman with CachyOS-specific features including INSTALLED_FROM tracking and automatic architecture detection. The repo installer will offer to install this. It works correctly but may produce compatibility warnings in scripts that expect standard pacman behavior. If you want the optimized packages without the custom pacman, you can add the optimized package repositories ([cachyos-v3], [cachyos-v4]) manually while keeping the upstream pacman binary.

Switching Kernels After Install

CachyOS makes kernel switching a normal package operation. Every variant in the lineup is available in the repository as a prebuilt package, complete with its own set of precompiled out-of-tree modules (NVIDIA, ZFS, and others). Switching does not require building anything.

# Install a different kernel variant (e.g. the BORE-only build)
$ sudo pacman -S linux-cachyos-bore linux-cachyos-bore-headers

# Install the Clang/ThinLTO variant
$ sudo pacman -S linux-cachyos-lto linux-cachyos-lto-headers

# List all installed CachyOS kernels
$ pacman -Q | grep linux-cachyos

# Remove a kernel variant you no longer need
$ sudo pacman -Rs linux-cachyos-bore linux-cachyos-bore-headers

After installing a new kernel, your bootloader will pick it up on the next reboot automatically -- Limine and GRUB both detect new kernels in /boot without requiring a manual config update on CachyOS. At the boot menu, select the kernel you want to test. If it behaves well, you can set it as the default; if it causes issues, boot back into your previous kernel and remove the new one.

Multiple kernels can coexist without conflict. The Kernel Manager GUI provides the same install and remove operations with a point-and-click interface if you prefer not to use the command line. Precompiled NVIDIA modules for every variant are available as nvidia-open-dkms equivalents that install alongside the kernel package, so NVIDIA users do not lose GPU functionality when switching.

Stability, Real-World Performance, and Who Should Use CachyOS

The honest answer on stability is that CachyOS inherits Arch's reliability profile -- which is good if you stay on top of updates and understand that a rolling release occasionally requires manual intervention after a major upstream change. CachyOS does not add instability on top of Arch; the custom kernels are well-tested before release, and the precompiled module approach eliminates a common source of breakage (failed DKMS builds after kernel updates). The project has grown substantially -- the 2025 year-in-review reported the community tripling in size -- which means more eyes on issues and faster community response to regressions.

What CachyOS does add is one additional variable: its own patchsets and package rebuilds. In practice, issues specific to CachyOS rather than upstream Arch are uncommon and typically resolved quickly. The CachyOS forum and Discord are active, and the developers are reachable. For a workstation where occasional manual recovery from a bad update is acceptable, CachyOS is as reliable as Arch. For a headless server or a machine where downtime is unacceptable, no rolling release distribution is the right choice regardless of which one.

On measured performance: Phoronix has benchmarked CachyOS against vanilla Arch and other distributions across multiple test suites, consistently finding CachyOS competitive to ahead in CPU-bound workloads. The gains are not uniform -- workloads that are I/O-bound or memory-bandwidth-limited see little difference, while compute-heavy tasks (compilation, compression, scientific workloads) and gaming scenarios with CPU bottlenecks see the clearest improvements. The 5--10 FPS gains reported in gaming benchmarks using x86-64-v4 packages on compatible hardware are representative of what the package-level rebuilds can produce in CPU-limited scenarios. The ~10% kernel throughput improvement from AutoFDO+Propeller is a kernel-level figure and stacks on top of, rather than competing with, the package-level gains.

Step 1: Download and verify the CachyOS ISO

Download the latest CachyOS ISO from cachyos.org. Verify the checksum provided on the download page before writing the ISO to USB. Use dd on Linux or Rufus on Windows. As of January 2026, the ISO ships with both a stable kernel and an LTS kernel, with the stable kernel as the default boot option. Limine is now the default bootloader rather than GRUB, and the live environment runs Wayland by default.

Step 2: Run the Calamares installer and select your kernel

Boot from the USB drive and launch the graphical Calamares installer from the desktop. At the kernel selection step, linux-cachyos is the recommended default -- it uses BORE scheduling, GCC Thin LTO, and AutoFDO+Propeller profiling. Choose linux-cachyos-lto if you prefer the Clang/ThinLTO compiler toolchain with the same profiling tier, or linux-cachyos-bore if you want a BORE build without the profiling passes. The installer will also install linux-cachyos-lts as an automatic fallback. Select your filesystem (Btrfs with zstd compression is recommended), bootloader (Limine is the default as of January 2026; GRUB remains an option), and desktop environment.

Step 3: Select your microarchitecture tier during installation

The CachyOS Hardware Detection tool (chwd) will detect your CPU and configure the appropriate optimized repository tier. Verify post-install that your /etc/pacman.conf includes the correct stanza: cachyos-v3 for x86-64-v3 CPUs, cachyos-v4 for x86-64-v4 (AVX-512), or cachyos-znver4 for AMD Zen 4 CPUs. Run grep cachyos /etc/pacman.conf to confirm. You can also check your CPU's supported tiers directly with /lib/ld-linux-x86-64.so.2 --help | grep supported, which lists the highest architecture level the dynamic linker detected. If the correct tier is missing, add the appropriate stanza manually and run sudo pacman -Syu to pull the optimized package set.

Step 4: Install and switch sched-ext schedulers post-install

After booting into your installed system, install the sched-ext packages: sudo pacman -S scx-scheds scx-tools. As of scx version 1.0.18, scxctl and scx_loader live in the separate scx-tools package rather than inside scx-scheds. Open scx-manager (the standalone sched-ext GUI split from the Kernel Manager in March 2025) or use the command line: sudo scxctl start -s scx_bpfland -m gaming. To make the choice persistent, enable the loader service: sudo systemctl enable --now scx_loader. The configuration is written to /etc/scx_loader.toml and applied on every subsequent boot.

AUR Compatibility and the CachyOS Pacman Fork

AUR packages work on CachyOS the same way they do on Arch -- build from source using makepkg or an AUR helper like paru or yay. The AUR itself is not aware of CachyOS and packages do not produce CachyOS-optimized builds by default; they compile to whatever the PKGBUILD targets, which for most packages is the standard x86-64 baseline. This is the expected behavior and does not cause compatibility problems.

The custom pacman fork CachyOS ships adds the INSTALLED_FROM field to track whether a package came from an official repo or was built locally, and automatic architecture detection that selects the v3/v4 repository automatically. If you are new to the package manager itself, the guide to understanding pacman covers standard Arch package management in depth. These CachyOS additions are backward-compatible with standard AUR workflows. AUR helpers are unaware of them but function correctly because the package format and dependency resolution are unchanged. The only scenario where the custom pacman causes friction is in scripts that parse pacman output and encounter the additional field, which is rare.

One practical note: when an AUR package lists a dependency that CachyOS has rebuilt with v3/v4 optimizations, pacman will resolve it to the optimized CachyOS version rather than the upstream Arch version. This is correct behavior and means AUR packages transitively benefit from the CachyOS package rebuilds for their dependencies.

Frequently Asked Questions

What is the default kernel in CachyOS and what makes it different from a stock kernel?

The default CachyOS kernel (linux-cachyos) runs the BORE scheduler on top of EEVDF, is built with GCC Thin LTO, and since February 2025 receives both AutoFDO profile-guided optimization and Propeller code-layout optimization using CachyOS's own workload profiles. According to CachyOS release notes, combining AutoFDO and Propeller yields approximately 10% throughput improvement and reduced latency compared to a non-profiled build. The separate linux-cachyos-lto variant is the same patchset compiled with Clang/ThinLTO instead of GCC, and also receives the AutoFDO+Propeller pass. All variants ship precompiled NVIDIA and ZFS modules to eliminate out-of-tree DKMS rebuild friction after kernel updates.

What is the BORE scheduler and how does it differ from the upstream EEVDF scheduler?

BORE (Burst-Oriented Response Enhancer) is a patchset that extends EEVDF (Earliest Eligible Virtual Deadline First) by tracking a per-task burstiness score. Tasks that yield CPU time frequently -- such as interactive applications -- receive more aggressive wakeup preemption and longer timeslices, while tasks that hold the CPU for extended bursts are weighted down. This makes BORE prioritize responsiveness under mixed workloads without fully abandoning EEVDF's fairness model. BORE is the default scheduler on linux-cachyos and is also present on linux-cachyos-bore, linux-cachyos-lts, linux-cachyos-rt-bore, linux-cachyos-deckify, linux-cachyos-mainline, and linux-cachyos-hardened. The linux-cachyos-server variant uses stock EEVDF without BORE.

Can I use sched-ext schedulers on CachyOS without rebuilding the kernel?

Yes, on most variants. Any CachyOS kernel except linux-cachyos-bmq and linux-cachyos-hardened supports the sched-ext (SCX) framework, which loads BPF-based schedulers at runtime from userspace. Install scx-scheds (scheduler binaries) and scx-tools (which provides scxctl and scx_loader, split into its own package as of scx v1.0.18), then start a scheduler with sudo scxctl start -s scx_bpfland -m gaming or use scx-manager's GUI. Enable persistence with sudo systemctl enable --now scx_loader; the active scheduler and mode are stored in /etc/scx_loader.toml.

What does x86-64-v3 or x86-64-v4 optimization actually mean for CachyOS packages?

The x86-64 microarchitecture levels are tiered instruction set targets. x86-64-v3 requires AVX, AVX2, BMI1, BMI2, FMA, and other extensions present in many CPUs manufactured after 2015. x86-64-v4 additionally requires AVX-512. When CachyOS recompiles packages for these targets, the resulting binaries use wider vector operations and more efficient instruction encodings that the standard x86-64-v1 baseline cannot emit. On compatible hardware this translates to lower instruction count and higher throughput for compute-heavy code paths.

What is the difference between linux-cachyos and linux-cachyos-lto?

As of February 2025, the primary distinction is compiler toolchain, not profiling tier. Both linux-cachyos and linux-cachyos-lto run BORE scheduling, use Thin LTO, and receive AutoFDO+Propeller profiling from CachyOS's own workload profile. linux-cachyos is compiled with GCC; linux-cachyos-lto is compiled with Clang/ThinLTO. Earlier versions of the article and older documentation described linux-cachyos-lto as the only profiled variant, but that changed when Propeller support was extended to the default GCC kernel. Per the CachyOS GitHub, linux-cachyos-lto is described as the variant utilizing "AutoFDO + Propeller profiling for optimal performance" with Clang -- both kernels now receive that same profiling pass. If you have no toolchain preference, the default linux-cachyos is the simpler choice; choose linux-cachyos-lto if you specifically want a Clang-compiled kernel.

If the default linux-cachyos already uses BORE, why does linux-cachyos-bore exist?

linux-cachyos-bore is a separate GCC-built kernel that carries the BORE patchset but does not receive the AutoFDO+Propeller profiling passes applied to the default linux-cachyos kernel. It exists primarily as an option for users who want BORE scheduling without the profiling overhead in the build pipeline, or who are testing BORE behavior in isolation. For most desktop users, the default linux-cachyos is the better choice since it combines BORE scheduling with AutoFDO+Propeller optimization.

Can I add CachyOS to an existing Arch Linux install without reinstalling?

Yes. CachyOS provides a repository installer script that adds the CachyOS keyring, mirrorlist, and appropriate optimized package repos to a running Arch system. Run curl -O https://mirror.cachyos.org/cachyos-repo.tar.xz, extract it, and run sudo ./cachyos-repo.sh. The script detects your CPU tier and adds the correct stanza to /etc/pacman.conf. After running sudo pacman -Syu, packages with CachyOS-rebuilt versions will be installed. You can then install any CachyOS kernel variant with sudo pacman -S linux-cachyos linux-cachyos-headers. To revert, run the same script with --remove.

Do AUR packages work normally on CachyOS?

Yes. AUR packages build from source with makepkg or an AUR helper like paru and work identically to vanilla Arch. The AUR itself does not produce CachyOS-optimized builds, so packages compile to standard x86-64 by default. However, AUR packages do resolve their dependencies to the CachyOS-rebuilt optimized versions where available, so they transitively benefit from the package-level rebuilds. The custom pacman fork CachyOS ships is backward-compatible with all standard AUR workflows.

What is linux-cachyos-eevdf and how does it differ from the default kernel?

linux-cachyos-eevdf runs the stock upstream EEVDF scheduler with the full CachyOS base patchset (CONFIG_CACHY tunables, aes-crypto patches, BBRv3, 1000 Hz timer) applied, but without BORE's per-task burstiness scoring on top. The default linux-cachyos kernel adds BORE on top of EEVDF, which promotes tasks that yield the CPU frequently and benefits mixed desktop workloads. linux-cachyos-eevdf removes that layer, leaving pure EEVDF scheduling with Cachy Sauce intact. It supports sched-ext. The practical use case is workloads where every process is CPU-bound and BORE's interactivity weighting adds scheduling overhead without benefit -- batch computation, rendering, or controlled benchmarking. For general desktop or gaming use, the default kernel is the better starting point.

What is linux-cachyos-deckify and should I install it on a non-handheld machine?

linux-cachyos-deckify is the default kernel for CachyOS's Handheld Edition, targeting the Steam Deck (LCD and OLED), ROG Ally, Legion Go, and Legion Go S. It carries BORE scheduling and the full CachyOS base patchset plus device-specific patches for suspend/resume reliability, power button handling, TDP control, screen orientation, and controller input systems (InputPlumber, HHD). The CachyOS wiki explicitly states it is unsupported on non-handheld hardware -- the patches are device-specific and provide no benefit on desktops or laptops. On handheld hardware, the recommended sched-ext scheduler is scx_lavd rather than scx_bpfland; LAVD was developed with Valve's involvement and is tuned for the alternating burst-and-idle workload profile of handheld gaming.

What filesystems does CachyOS support at install time, and what happened to Bcachefs?

The Calamares installer supports Btrfs, ext4, XFS, and F2FS. Btrfs with zstd compression is the recommended default and what the installer selects unless you override it. It is the only filesystem that enables bootable snapshots from the boot menu via Limine or GRUB integration, which is what makes rolling back a broken update possible without a live ISO. ext4 and XFS are solid choices for users who want mature, widely-understood filesystems without snapshot support. F2FS (Flash-Friendly File System) is available as an option primarily for flash storage use cases, though Btrfs is generally preferred even on SSDs due to its snapshot capabilities. Bcachefs was removed from the CachyOS installer as of the March 2026 release. The filesystem had been available as an experimental option but was pulled after stability concerns. Users already running Bcachefs on existing installs are not affected, but new installations can no longer select it through the graphical installer.

Sources and Verification

The technical claims in this article are drawn from the following primary sources. All were reviewed in April 2026.

• CachyOS Kernel Wiki -- authoritative reference for kernel variant descriptions, scheduler assignments, sched-ext compatibility, and precompiled module list. Last updated February 2026.
• Why CachyOS? (CachyOS Wiki) -- official description of the EEVDF and BORE scheduler options. Last updated January 2026.
• CachyOS/linux-cachyos on GitHub -- PKGBUILD sources and README confirming both linux-cachyos (GCC) and linux-cachyos-lto (Clang) receive AutoFDO+Propeller profiling.
• CachyOS sched-ext Tutorial -- scheduler list, scx_loader usage, scx-tools package split, and scxctl reference. Updated March 2026.
• CachyOS Kernel Manager Wiki -- Kernel Manager configuration options, custom build flags, and sched-ext GUI management.
• CachyOS February 2025 Release Notes -- confirms Propeller optimization was extended to the default linux-cachyos GCC kernel once LLVM 19 landed. This is the authoritative source for the AutoFDO+Propeller change.
• CachyOS March 2025 Release Notes -- confirms scx-manager split from Kernel Manager and DLSS Swapper integration.
• CachyOS January 2026 Release Notes -- confirms Limine as new default bootloader, Wayland default live environment, stable kernel as ISO default, and architecture detection at start of install process.
• CachyOS March 2026 Release Notes -- confirms KDE Plasma 6.6.2, updated Calamares with animated DE previews, Winboat integration, and Bcachefs removal from filesystem selection.
• CachyOS 2025 Year in Review -- confirms NTSync and WoW64 defaults in Wine, community growth, and annual optimization milestones including Propeller on the default kernel.
• firelzrd/bore-scheduler on GitHub -- BORE patchset source, burstiness score implementation, and changelog.