Debian 11093 Ubuntu 7245 Arch Linux 1026 Published by

Liquorix 7.2-21 released on October 21, 2026, built on top of stable Linux 7.2.12 with maintainer Steven Barrett's usual low-latency tuning. Its headline change upgrades the compressed-swap system to "zswap v4 and zram v5," folding in four upstream patches that cut lock contention and speed up memory swapping when RAM runs tight. It's deliberately the most conservative of the project's recent builds, stepping away from the experimental MGLRU-FG memory code shipped in 7.2-20. Gamers and multimedia users can install it via a one-line script.



Liquorix 7.2-21 arrives as the most conservative of the project's recent builds, on purpose

Steven Barrett, the person almost entirely behind the Liquorix enthusiast kernel, pushed a new build on Wednesday. It's tagged 7.2-21 and rides on top of upstream Linux 7.2.12, so you get the full stable point release plus his usual responsiveness tuning. But the version number is the less interesting part of this release.

The more interesting part is what he did to the swap system. Barrett upgraded Liquorix's compressed-swap handling to what he calls "zswap v4 and zram v5." That's a fresh batch of memory-management optimizations lifted from mainline, aimed at making the swap path faster and less contended. If your system ever runs low on RAM and starts pushing pages in and out of compressed memory, this is exactly the code that shows up in your hot path.

For what it's worth, the name sounds impressive for a swap subsystem, but that's kind of the point. Swap work only gets noticed when things go wrong.

Liquorix

Why the swap rework matters

The timing isn't coincidental. RAM prices have been sky high, which has turned efficient memory use into a first-class concern for kernel developers. When you fill up physical RAM, the kernel has to evict pages somewhere, and two mechanisms dominate the compressed-swap space.

zram builds a virtual block device inside RAM that compresses pages on the fly. It trades CPU cycles for less disk I/O and it's fast, but it compresses everything, even poorly-compressible junk, and the kernel can't see much of what it's doing. zswap, meanwhile, sits as a write-through cache between your page-out path and the actual swap device. It compresses pages into a bounded pool and only falls back to disk when the pool is full or the data simply won't compress.

Chris Down wrote a detailed 2026 analysis debunking some long-circulating myths about both, and he landed on zswap for most cases. He noted it integrates much more tightly with the rest of the memory-management subsystem and degrades gracefully under pressure. zram's niches are real but narrower: diskless embedded boxes, or workloads where any disk access counts against you.

The core problem both projects fight is lock contention on the compression path. A low-priority store can be preempted right after dropping its stream lock while it still holds the zswap mutex, and then a higher-priority load on that same CPU waits for the store to run again. The fixes separate compression and decompression into their own streams and locks, keeping the read path from taking a global lock. Reported results were striking, with over-10ms reads dropping from the dozens per run to basically none.

Barrett folded in exactly four upstream changes for this release's swap work. zram can now borrow an idle decompression stream from another CPU rather than allocating a fresh one, which cuts contention when multiple cores read swapped data at once. A new bounce buffer handles objects that span multiple internal buffers, a correctness fix that also helps with large or split objects. zram gets shared decompression streams, mirroring the earlier zswap work, so decompress ops no longer each grab their own lock. And a lower-level crypto patch caps synchronous compression request sizes, which keeps pathological large allocations in check. All of it points at one goal: faster, less contended compressed swap when memory is tight.

Keep in mind this is a desktop kernel. Those server-and-database benchmark numbers that circulate for this kind of work don't necessarily translate to your gaming rig.

What Liquorix actually is, and whether you want it

Barrett has been tagging builds at a blistering pace through the 7.2 cycle. 7.2-19 and 7.2-20 both landed on October 16 within roughly an hour of each other. The real story is what 7.2-21 deliberately skipped. The previous experimental build, 7.2-20, folded in Kairui Song's still-in-review MGLRU Frequency Guided v4 patch set, a server and Android-oriented memory technology reaching a desktop gaming kernel for the first time. Benchmarks were dramatic on paper, +10% to +47% on database and web workloads. Those were database, web, and Android loads, though. Nobody's proven it actually helps games.

7.2-21 steps away from that experiment. It's a clean 7.2.12 base plus the swap rework, no experimental memory code, which makes it the more sensible choice in the current lineup. For people who want the bleeding edge, Barrett publishes separate builds and flags them as experimental.

Liquorix bills itself as a "distribution kernel drop-in replacement," a specific promise. It aims to run broadly across hardware rather than being a fragile custom build that needs manual driver work. It shares a tuning profile called Zen Interactive Tuning with Barrett's sibling Zen kernel.

The project is refreshingly honest about what it does. Its own documentation states plainly that it's a myth that custom zen kernels magically give you 20% more speed. They don't. What these kernels do is favor responsiveness at the cost of sustained throughput and power efficiency. Battery life can suffer, and heavy compile jobs might run a touch longer. The kernel chooses to feel live under interactive load rather than maxing out benchmarks.

The config knobs back that up. Liquorix switches the I/O scheduler to kyber or bfq, ramps CPU frequency sooner by lowering its thresholds, and shortens the scheduling timeslice so tasks yield the CPU more frequently. It even disables split-lock detection, dropping a small per-operation penalty in exchange for losing a mitigation that mostly affects older hardware anyway.

Liquorix ships with a PDS/BMQ scheduler instead of the stock CFS, a 1000 Hz tick rate, hard kernel preemption, and TCP BBR3 congestion control. The scheduler is the thing most people cite as the selling point for low input lag. For what it's worth, experienced users consistently report that XanMod and Liquorix land within a fraction of a percent of each other in raw benchmarks, so the choice usually comes down to scheduler preference and your specific workload.

If you want to try 7.2-21, there's a one-line script covering Debian, Ubuntu, and Arch.

curl -s 'https://liquorix.net/install-liquorix.sh' | sudo bash

You do still get upstream security fixes, though. Because Liquorix tracks mainline stable closely, 7.2-21 carries the same bug and security patches as stock 7.2.12.

Head here to the GitHub repo for the full changelog.