Debian 11072 Ubuntu 7215 Arch Linux 1012 Published by

Liquorix Linux Kernel 7.2-11 has been released. The release caps the project's fastest pace ever, with seven packages going out in a ten-day window from 7.2-5 to 7.2-11. Most of the action happened in the surrounding builds, especially the Project-C scheduler tweaks and the 7.2-8 dmem-ttm-v8 memory patch that helps low-VRAM and integrated-GPU systems. It is a clean baseline with prior patches carried forward, so the real value stays in Liquorix's hand-tuned scheduler rather than any new version lead.



Liquorix ships 7.2-11, jumping over v7.2.5 after its most packed sprint yet

The latest release merges upstream Linux 7.2.6 and caps the project's fastest release cadence ever: seven packages in ten days.

Liquorix shipped kernel 7.2-11 today and the release note is about as terse as they get. A single line. An upstream merge. A version bump. No fanfare. Strip away the brevity, though, and this one carries real weight: maintainer Steven Barrett merged v7.2.6 straight past v7.2.5, skipping the earlier stable release entirely.

The pattern was set earlier in that same September 1-14 window, a ten-day stretch where seven straight packages landed, from 7.2-5 to 7.2-11. That is the fastest pace in the project's recent memory, and a pace that would make most maintainers sweat.

Keep in mind that 7.2-11 itself is a merge tag. Like all of those, it bundles no new Project-C scheduler patches. The actual labor happened in the packages it sits on, which is where the sprint gets interesting.

Liquorix

The sprint's real story

Between 7.2-10 and 7.2-11, Barrett's base kernel hopped from 7.2.4 to 7.2.6. He folded two upstream releases into one move. That is unusual for a stable line. Either 7.2.5 was a wash he didn't need to carry, or he wanted a cleaner baseline heading into the feature-freeze tail of the 7.2 line. The changelog stays quiet on the why, and nobody has said.

The surrounding releases read more like a lab notebook than a changelog. 7.2-5 introduced SMT balance changes, 7.2-6 reverted them, and then 7.2-9 and 7.2-10 rebuilt the idea with adjustments. Add. Revert. Refine. It is the Liquorix playbook: ship a heuristic, watch the bug tracker, and converge on something that holds up.

Then there was 7.2-8. That release pulled the earlier "vramstuff" branch and swapped in a dmem-ttm-v8 patch set, letting low-VRAM and integrated-GPU systems carve out dynamic RAM as translation-memory backing for GPU buffers. Same idea Liquorix floated back in April as dmemcg v6, matured. If you run an AMD chip with a decent iGPU, it is the one feature most likely to touch your daily use.

It is also worth noting that the YouTube-in-Firefox freeze problem still floats around the tracker, a recurring snag across versions. That probably explains why the whole Project-C effort feels less like a rewrite and more like a long grind against exactly that kind of desktop stall. Oddly, the repo is eerily calm for a project producing this much code. One open issue, a Fedora support question, perched on top of 230+ since early 2026.

Why the custom scheduler still matters

The sprint is basically a live look at Project-C, Barrett's codename for a sustained hardening pass over Liquorix's custom sched/alt scheduler. The changes that dominate it are the surgical kind: hold a sync wakee on the waker's core until it fills up, handle busy wakers, sort out task placement on non-SMT cores. Cache-line alignment, bounded task walks, use-after-free fixes. All the boring, unglamorous work that keeps a box from freezing mid-video-call.

It is a deliberate stance. Upstream Linux has drifted toward EEVDF, and Barrett keeps doubling down on his hand-tuned PDS/BMQ-heritage scheduler instead, on the theory that it beats stock for interactive workloads. For gaming and A/V, frame-time dips are visible and annoying, and that is the whole game.

Two releases in this window chased system freezes directly. 7.2-8 came back after an earlier SMT/idle optimization proved problematic, this time with a freeze fix layered in. The project has been circling that same kind of hard freeze since at least June, so this is a problem Barrett has been wrestling with for months.

The community context makes the obsession legible. Of the open issues, a good chunk are freezes, on a Ryzen 5 5500U, on Intel Comet Lake, during Firefox. The user base reads clearly as gamers and desktop users who cannot afford a stall. That is what produces a near-daily iteration cadence aimed almost entirely at scheduler stability and SMT behavior.

The numbers, if you are tracking

It works out to roughly twenty releases in under six weeks, from 7.1-21 to 7.2-11. A few went out on the same day, including the 7.2-3 and 7.2-4 pair and the 7.2-7 and 7.2-8 pair. Version-wise, 7.2-11's internal version is 7.2.6-1.

Nothing about the architecture changed. It is still AMD64 only, still built with Docker multi-stage builds, still installable via the one-line curl-to-bash script:

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

Liquorix still positions itself as a drop-in for Debian Stable, Testing, and Unstable, plus Ubuntu and Arch.

The 7.2-11 tag is a clean baseline with the prior patches carried forward, and that is the whole point. You are not paying for kernel-version lead. You are paying for the applied patchset and the config, which in this sprint means a scheduler that has been poked at more times than a toddler pokes a road.

It is arguably the most ambitious custom-scheduler effort still running in the enthusiast space. Whether those tweaks actually pay off depends on whether they hold without regressions, and the tracker makes clear that "without regressions" has been the hard part. The cadence, though, says plainly what matters to Barrett right now: responsiveness, and not shipping ones that break your desktop.

Head here for the release page.