Linux 7.3 opens its merge window as an LTS candidate and finishes sched_ext

1,250 patches. 705 milliseconds. 1,024 accelerators. Linux 7.3 entered its merge window in mid-August 2026, right on the heels of the Linux 7.2 release on August 17. The cycle is shaping up as this year’s LTS candidate, and it carries three promises: sharply faster memory management, a now-complete sched_ext, and the opening of two hardware fronts — AMD UALink and the Apple M3. For an administrator, what happens now is not trivial: whatever lands in 7.3 stays maintained for years if it earns LTS status.

The LTS candidate that locks in choices

The merge window is the moment subsystems land their contributions on Linus Torvalds’s main branch, ahead of the release candidates. If 7.3 is indeed chosen as Long Term Support, every decision made today gets a multi-year lifespan — which is why the density of this cycle counts double.

The clearest signal comes from the memory subsystem: Andrew Morton shipped a pull request of 1,250 patches, up from 920 in the previous cycle. That is a rise of more than a third, concentrated on optimizations aimed at memory-constrained workloads — servers, Android, zRAM and Zswap. The unusual volume even pushed Morton to lean on Gemini to draft his patch summaries, so heavy was the flow.

Two memory bottlenecks fixed

Two fixes deserve special attention, because they hit pain points that teams measure in milliseconds.

The first is signed by ZTE and targets rmap_walk_ksm(). The engineers found a severe performance bug: under memory pressure, applications could freeze for hundreds of milliseconds. The fix brings the worst-case lock hold time down from 705 ms to a 1.44 ms average. Directly affected are JVM and Go runtimes, and database engines like MySQL and PostgreSQL, which create tens of thousands of VMAs sharing a single anon_vma.

The second is signed by Wenchao Hao of Xiaomi and tackles lock contention in zsmalloc. The result: up to a 1.83× speedup on a Raspberry Pi 4B under concurrent unmapping workloads, and 1.4× on a 20-core Intel system. It is the fix that Zswap and zRAM users — the majority of Android devices and RAM-frugal servers — have been waiting for.

sched_ext becomes complete

sched_ext — the framework for writing schedulers in BPF — is declared feature complete in this cycle. The headline addition is hierarchical sub-scheduling: a root BPF scheduler can hand a cgroup subtree to a nested sub-scheduler with revocable CPU grants. Arena objects now cross the kernel/BPF boundary as typed pointers, and rescue execution for starved tasks runs on a small bandwidth budget instead of waiting for watchdog ejection.

For teams wanting to confirm their kernel ships the framework, one check suffices:

# Confirm sched_ext is present in the running kernel configuration
grep SCHED_CLASS_EXT /boot/config-$(uname -r)

The maturity of sched_ext is not a footnote: it is what lets you experiment with a custom scheduler without recompiling the kernel, then switch it on in production once it has proven itself.

Reaching feature-complete status matters precisely because 7.3 is the LTS candidate: a scheduler framework frozen into a long-term kernel has to be trustworthy, and the hierarchical sub-scheduling that lands now is the feature set the LTS will carry for years. Operators who want sched_ext in a supported kernel get it here, not in a point release.

The hardware that opens up

The 7.3 cycle is also a heavy hardware delivery. AMD receives a 95-patch series adding UALink support to AMDGPU: an open standard able to connect up to 1,024 accelerators in a single domain, where GPUs access remote memory directly without copying — unlike RDMA — through a dedicated Network Physical Address space. The first in-tree CXL Type-2 driver also lands for the AMD Solarflare SFC9100 network cards.

On the Apple side, the M3 Pro, M3 Max and M3 Ultra gain initial Device Tree support in the mainline kernel — the foundation the Asahi Linux project was waiting for, even if GPU acceleration remains out of scope. Rust in the kernel gains another architecture with PowerPC (32- and 64-bit). And NTFS3 gets a 922-line, 21-commit security overhaul, fixing out-of-bounds writes, out-of-bounds reads and information leaks, while adding support for alternate data streams (ADS).

The anecdote that says a lot: Linus, Gemini and one character

The cycle produced a story that sums up kernel development in 2026. Linus Torvalds personally tracked down a bug in the Intel Xe driver that caused black screens on Battlemage G21 GPUs. The cause: a subtle VRAM offset miscalculation in get_flat_ccs_offset(), fixed by one character — switching round_up() to round_down(). It took him 24 patches of debug code and 18 kernel boots, with Gemini as his tireless helper, and the final commit message was written by the AI.

The anecdote is not mere entertainment. It intersects a deeper debate of the cycle: the influx of AI-generated patches, which the community says drowned ARM64 development during the 7.2 cycle — no real feature landed for AArch64 in that window, a gap that 7.3 is only starting to close. The quality of AI-assisted contributions is now a kernel maintenance topic, not a blog topic.

The rest of the cycle: filesystems, crypto and the calendar

The filesystem side is not idle either. ext4 unlocks parallel DIO writes where safe, and the ext4_mb_prefetch() optimization for fallocate() skips unnecessary work. btrfs drops free space v1 as the default in favor of the free space tree v2 — already the mkfs default since kernel 5.15 — while keeping backward compatibility for existing filesystems.

On the crypto side, a new af_alg_restrict sysctl with a whitelist lets administrators restrict which algorithms the AF_ALG socket interface exposes to userspace. It is a targeted hardening of surface area: closing one door into kernel crypto rather than leaving it wide open.

The calendar remains the anchor: Linux 7.3 is expected around October 2026, with a first release candidate in the coming weeks. In the meantime, the memory fixes will trickle down to stable branches — meaning this cycle’s value is not limited to those who adopt the major release on day one.

For operators, the practical takeaway is to start reading the 7.3 merge-window coverage now rather than at release time: the fixes that matter — the two memory patches above all — are already identifiable, and an LTS decision would lock them in for the long term.

Verdict

If you run servers or hosts under memory pressure — Zswap, zRAM, databases, JVM or Go runtimes — plan the move to Linux 7.3 when it lands around October 2026: the rmap_walk_ksm() and zsmalloc fixes translate into measurably lower tail latencies, and the likely LTS status guarantees they stay maintained for the long haul.

If your estate is heterogeneous or pinned to an older stable branch, do not force it: the memory fixes will trickle down to stable branches, but the full benefit of sched_ext and UALink support only makes sense for those able to adopt the major version. For everyone else, just make sure whichever branch you keep picks up those two memory fixes — they will pay off fastest.

References

• Linux Kernel 7.3: What’s New in the Upcoming Kernel Release — Linux Compatible, August 2026
• Kernel coverage — LWN.net, accessed August 27, 2026