CachyOS/linux-cachyos: one kernel fork, three schedulers, and eight packages

This repository is kernels, not the distribution

The first thing to get straight is scope. This repository builds kernels. The distribution, its repositories and its installer live in separate CachyOS projects, and this README does not describe an operating system you install.

What it does describe is a collection of enhanced Linux kernels built from the CachyOS Linux fork, currently based on Linux 7.1, which merges topic branches on top of upstream stable releases. That phrasing matters. The kernels are not a fork that diverges wholesale from upstream, they are upstream stable with a named set of topic branches layered on, which is a considerably easier thing to reason about when deciding whether to run one.

The branch list is explicit: `amd-isp4`, `bbr3`, `cachy`, `cgroup-vram`, `drm-fair`, `fixes`, `hdmi`, `lenovo-wmi`, `mglru`, `preempt-ipi`, `sched-cluster`, `snd-codecs`, `t2`, `vesa-dsc-bpp` and `vmalloc-free`. Fifteen of them, each one a small, nameable intervention rather than an open-ended patch set. Several map to hardware, with `amd-isp4` for AMD display, `hdmi`, `lenovo-wmi` for laptop firmware and `t2` for Apple silicon hardware support.

One thing worth flagging for anyone tracking versions: the README describes the fork base as Linux 7.1, while the recent tags on the repository are in the 6.x line, with 6.17.9 published on 2025-12-01, before 6.14.8 in May 2025 and 6.13.7 in March 2025. The `linux-cachyos-lts` variant is separately noted as sitting at 6.18. So the base moves quickly and the tags reflect different points in that movement.

Three schedulers, three package families

The variant table is the core of this project and it is unusually well organised. Each row names a scheduler, expands its acronym, lists which packages carry it, states what it is best for, and credits its developer.

BORE stands for Burst-Oriented Response Enhancer, by firelzrd, and is listed for interactive workloads and gaming. It ships in four packages: `linux-cachyos-bore`, `linux-cachyos-deckify`, `linux-cachyos-hardened` and `linux-cachyos-rt-bore`.

EEVDF, Earliest Eligible Virtual Deadline First, by Peter Zijlstra, is the general-purpose option and covers `linux-cachyos`, `linux-cachyos-eevdf`, `linux-cachyos-lts` and `linux-cachyos-server`.

BMQ, BitMap Queue CPU Scheduler, by Alfred Chen, is described as throughput-oriented and ships as `linux-cachyos-bmq` alone.

That structure has a consequence worth noticing. The scheduler is not a compile-time flag inside one package, it is a package boundary. Each directory in the tree corresponds to a package, so the eight or so kernel directories are the real API of this project.

linux-cachyos
linux-cachyos-bmq
linux-cachyos-bore
linux-cachyos-deckify
linux-cachyos-eevdf
linux-cachyos-hardened
linux-cachyos-lts
linux-cachyos-rt-bore
linux-cachyos-server

The specialised variants layer other things on top. `linux-cachyos` is the default: EEVDF with Clang Thin LTO and AutoFDO. `linux-cachyos-rc` tracks the next upstream version. `linux-cachyos-hardened` adds hardening patches on BORE. `linux-cachyos-rt-bore` is the real-time build. `linux-cachyos-server` is an EEVDF configuration with lazy preemption. `linux-cachyos-deckify` is the handheld gaming variant, with Steam Deck support and the MSI Claw driver.

The README's advice is to test each scheduler rather than trust the table, which is the right instruction given that scheduler choice is workload-dependent in ways no table can capture.

Compiler and microarchitecture choices are separate axes

Scheduler is the axis the README leads with, but it is not the only one, and conflating the two leads to the wrong conclusion about what a given package does.

The compiler axis is separate. The default `linux-cachyos` build uses Clang Thin LTO with AutoFDO plus Propeller profile-guided optimisations. The scheduler-specific packages, bore, bmq and eevdf, are GCC-compiled builds without LTO, focused on scheduler choice rather than compiler optimisations.

That is a real trade. LTO and profile-guided optimisation buy throughput at the cost of long compile times and a less predictable build, while a plain GCC build of the same source tree gives you a different performance profile than the default package with the same scheduler. If you are benchmarking schedulers, the compiler difference is a confound, and the scheduler-specific packages are the ones built to be comparable.

The third axis is microarchitecture level. Every kernel is available in `x86-64`, `x86-64-v3`, `x86-64-v4` and `znver4` builds, and the tree carries `script.sh`, `script-v3-v4.sh` and `script-znver4.sh` for them. x86-64-v3 and v4 are instruction set levels, so a v3 kernel will not run on hardware that lacks those instructions. There is AMD Zen 4 specific support as well, and a CPU compatibility check is offered in the README's installation section, which is the right way to find out which level your processor supports.

Two compiler details are listed under CPU enhancements rather than build options, which is a reminder that they affect runtime behaviour rather than only the binary. Kernel Control Flow Integrity, kCFI, is available when using LLVM, and Cachy Sauce is a custom `CONFIG_CACHY` configuration carrying scheduler and system tweaks.

Latency work, from timer frequency to LIFO accept

The CPU enhancements section is where the fork's actual engineering shows, and most of it targets responsiveness rather than raw throughput.

The POC Selector, a fast idle CPU selector inspired by scx_cake and taken from masahitoS's project at version 2.6.2, reduces wakeup latency by choosing which CPU an idle task lands on. Cluster-aware scheduling improves load balancing across CPU clusters, including balancing between CPUs of identical capacity on hybrid architectures, which is the case where the naive balancer wastes energy.

Preempt-IPI optimisations lower the latency of the SMP inter-processor interrupt path, with preemption re-enabled before TLB flushes and streamlined `smp_call_function()` handling. The ordering detail is the kind of thing that only matters if you profile, and it says the fork is being tuned with measurement rather than by applying patches.

Two smaller changes are easy to appreciate. `sched/wait` LIFO accept() processes socket connections in last-in-first-out order for better cache locality, which is a deliberate departure from FIFO and a good example of a kernel fork making a judgement call you would not make yourself. Wakeup CPU affinity prefers the CPU a task last ran on, trading a small amount of balancing freedom for cache locality.

Timer frequency is configurable between 100Hz, 250Hz, 300Hz, 500Hz, 600Hz, 750Hz and 1000Hz, defaulting to 1000Hz. That default trades power for latency and is the single most consequential setting for a laptop, which is why PREEMPT_DYNAMIC is offered alongside it, letting you select full, lazy, voluntary or none preemption modes at runtime rather than at build time.

Filesystem, memory and networking changes

Beyond scheduling, the README lists a set of subsystem-level additions that are more conventional and easier to evaluate on their merits.

ZFS support is built in with pre-compiled modules, which removes the usual step of building ZFS against a specific kernel configuration. NTFS improvements are described as upstream driver fixes covering MFT mirror validation, attribute bounds checking and logfile handling, so those are correctness fixes rather than new functionality. MGLRU enhancements continue the multi-generation LRU work, and the `mglru` topic branch in the base list confirms it is maintained as its own branch.

vmalloc optimisations are named precisely: bulk page freeing in `vfree()`, improved shrink and grow paths in `vrealloc()`, and optimised contiguous range freeing. Those are allocator-level changes with a plausible mechanism, since batching frees reduces per-call overhead.

Networking is a single item, BBR3 TCP congestion control from Google's BBR work, available as a separate module alongside BBRv1. Shipping it as a module rather than built in is the conservative choice, since you load it when you want it.

`cgroup-vram` and `drm-fair` in the branch list point at GPU-adjacent work: memory accounting for cgroups and fair scheduling for direct rendering manager drivers. Neither is described further in the visible feature list, which is a fair indication of how far each branch is documented at the README level versus in the wiki it links to.

Releases, maintenance and what the repository is not

The metadata is straightforward. GPL-3.0 licensed, Shell as the primary language, which makes sense for a repository of PKGBUILDs and shell scripts rather than kernel source, 4,491 stars, 161 forks, 130 open issues, `master` as the default branch, not archived, with the last push on 2026-09-21.

The low fork count relative to stars is informative. People use these kernels; they do not fork them. For a distribution-scale project that is the healthy shape.

The top-level tree shows the release machinery. There are `script.sh`, `script-v3-v4.sh` and `script-znver4.sh` for the architecture variants, `srcinfo.sh` for generating the repository metadata that Arch-style repositories need, and `tag-release.sh` for tagging. Alongside them sit `CONTRIBUTING.md`, `CODE_OF_CONDUCT.md` and `LICENSE.md`.

Note the language. This repository does not contain kernel source. It contains the packaging and the scripts that produce the kernel packages, and the source itself comes from the CachyOS Linux fork linked in the README. So a contributor here is usually adding or adjusting a PKGBUILD, not touching a scheduler.

The README is detailed about features and points outward for depth, linking a kernel wiki page for per-variant explanations, a blog post on AutoFDO, and SCX scheduler documentation. That split is sensible for a project with this many build combinations. The gap a reader should be aware of is that the wiki is where the detail lives, and this page is where the decisions are summarised, so the two need to be read together before committing to a kernel on a machine you care about.

Editorial conclusion

The kernel repository is coherent in a way the distribution around it is not, because the README explains what each build actually changes rather than listing feature names. You can read the table and know that BORE targets interactive workloads, EEVDF is the general-purpose default, and BMQ is the throughput option, and the specialised variants are honest about what they trade away, with the hardened build carrying hardening patches and the server build using lazy preemption. The practical entry point is `linux-cachyos`, since that is the default with EEVDF, Thin LTO and AutoFDO, and `linux-cachyos-lts` is the choice if you want a kernel that is not tracking the newest upstream base. Since each variant is its own package, switching schedulers is a package swap rather than a rebuild, which makes the recommendation to test each one cheap to follow.

Frequently asked questions

Official sources

1. CachyOS/linux-cachyos on GitHub
2. License: GPL-3.0
3. Project website
4. README
5. Releases