Linus Torvalds tagged Linux 7.3-rc1 on Sunday, August 30, 2026, closing a two week merge window that opened right after 7.2 shipped on August 17. The headline is size: roughly 15,267 commits pulled, which reporting puts second only to 6.7 in kernel history, and a tree that now sits at about 40.98 million lines. Read past the counting and there are three performance changes worth planning around, a pile of hardware that boots without out of tree patches for the first time, and a debugging story that says something about how kernel work is changing.
The short answer
Linus Torvalds tagged Linux 7.3-rc1 on August 30, 2026. It is one of the largest merge windows on record by commit count, and the line count jump comes mostly from a generated AMD DCN6 register header rather than from new logic. Three performance changes stand out: Btrfs direct input and output moving from roughly half of theoretical throughput to roughly 95 percent, a boot time BMI2 probe cutting Zstd decompression time by 71 percent, and a multi generation LRU fix that took an ARM server build from 9,248 to 7,861 seconds of system time. On the hardware side, USB4 and Thunderbolt arrive for Apple M1 through M3, Intel Xe3P with Nova Lake is enabled by default, AMD Zen 6 enablement continues, and the 2026 Valve Steam Controller gets a kernel driver.
Every few releases someone notices the kernel crossed another round number and treats it as news. This time the round number is about to be 41 million lines, and it is worth explaining why that figure is close to meaningless before getting to the parts of 7.3 that are not.
The size is real, the line count is not the reason
The commit count is the honest measure, and 15,267 is a lot. Reporting places it second in kernel history behind only 6.7. That is a genuine signal about how much work landed in two weeks.
The line count is a different story. The tree grew toward 40.98 million lines largely because of a register header dump for AMD DCN6, the display core in upcoming AMD graphics silicon. Register headers are generated, they are almost entirely constant definitions, and nobody edits them by hand. Phoronix now puts the AMD kernel graphics driver on its own at roughly 6.5 million lines, which is more than the entire kernel weighed not that long ago. It says something about the size of a modern GPU programming surface and nothing at all about kernel complexity in the sense people usually mean.
Memory management is where the reviewable work concentrated: about 1,250 patches this cycle against roughly 920 in the previous one.
Three numbers worth planning around
The Btrfs change is the one most likely to alter a capacity plan. Improvements to the iomap bounce buffer path lift direct input and output from roughly 50 percent of theoretical maximum throughput to roughly 95 percent. That is not a tunable, it arrives with the kernel. We have written about the Btrfs direct I/O and fsync work as it landed, and rc1 is the point where it becomes something you can benchmark end to end rather than read about.
Zstd got the kind of fix that is embarrassing and delightful in equal measure. The code was calling CPUID repeatedly to test for BMI2 support. CPUID serializes the pipeline, so every call in a hot path costs far more than the check is worth. Linux 7.3 probes once at boot and remembers. The measured result is 71 percent off decompression time and 18 percent off compression for crypto_acomp. Compressed Btrfs volumes, zram swap, initramfs unpacking and squashfs images all sit downstream of that.
Third, a multi generation LRU fix showed up clearly on ARM servers, dropping system time on a build workload from 9,248 seconds to 7,861, around 15 percent. That follows the same thread as the MGLRU change that stopped evicting hot executables: 7.3 has spent an unusual amount of its budget on reclaim behaviour under real pressure rather than on synthetic wins.
Hardware that stops needing patches
Apple silicon gets the most visible step. Initial USB4 and Thunderbolt support arrives for M1 through M3, alongside a new Apple PMGR driver for power management. That builds directly on the M3 Pro, Max and Ultra boot support merged earlier in this cycle, and it is the difference between a machine that runs Linux and a machine you can dock.
On x86, Intel Xe3P graphics with Nova Lake are enabled out of the box rather than behind a force probe flag, initial Intel Starfire enabling appears, and there are new optimisations for hybrid performance and efficiency core scheduling plus Directed Package Thermal Interrupt support in the thermal driver. AMD Zen 6 platform enablement continues to accumulate. Nouveau picks up NVK Vulkan Video. Rust in the kernel gains PowerPC support, which quietly widens where new Rust drivers can be deployed. And yes, the 2026 Valve Steam Controller has a kernel driver.
Filesystems and virtualisation
F2FS took 51 commits, adding resizable tail sections and parallel flushes across multiple devices. CephFS changed a default that has annoyed operators for years: synchronous writes while a cluster is near full are now opt in rather than forced on you. KVM landed a 45 patch series reworking guest memory conversion, on top of the kvm_mmu split we covered when the pull landed.
There is also a small story about method rather than code. Torvalds used Google Gemini to chase an Intel Xe graphics regression, describing it as a tireless helper while noting the process took 24 debug patches and 18 kernel boots to reach an answer. That is not a machine writing kernel code. It is a maintainer using a model as a patient bisect partner on hardware he cannot easily reproduce, which is a much less exciting claim and a much more useful one.
What to do now
If you maintain kernels, pull rc1 onto spare hardware, especially anything with Apple silicon, Nova Lake or Zen 6 in it. That enablement code has been tested mostly by the people who wrote it, and rc1 is the moment outside boots start finding what they missed. If you run Btrfs or lean on kernel Zstd, build a benchmark now against your current kernel so the October comparison means something.
If you run production, do nothing yet. Six weeks of release candidates is exactly the point.
Sources and further reading
- Linux 7.3-rc1 With AMD Zen 6 Additions, Better Btrfs Performance and 2026 Steam Controller, Phoronix, August 30, 2026
- Linus Torvalds Announces First Linux Kernel 7.3 Release Candidate, 9to5Linux, August 30, 2026
- Linux Kernel 7.3 RC1 Merge Window Closes With Heavy DRM, Filesystem, and AI-Assisted Debugging, LinuxCompatible, August 2026
- Linux Kernel 7.3-rc1 Released: 41M Lines, Apple Thunderbolt, and KVM Overhaul, Warp2Search, August 31, 2026
Frequently asked questions
Why did the kernel jump toward 41 million lines in one release?
Almost all of it is one thing: a register header dump for AMD DCN6, the display core generation in upcoming AMD graphics hardware. Register headers are machine generated, enormous and almost entirely constant definitions, so they inflate a line count without adding much anyone reads or maintains by hand. Phoronix put the AMD kernel graphics driver alone at roughly 6.5 million lines. If you want a number that tracks real change, look at the commit count instead, and 15,267 is genuinely large.
What is the single biggest performance change for servers?
The Btrfs direct input and output work, which reporting puts at roughly 95 percent of theoretical maximum throughput against about 50 percent before. The fix is in how the iomap bounce buffer path is handled, so it is not a mount option you turn on, it is behaviour you inherit by upgrading. If you run databases or object storage on Btrfs and you have been treating direct writes as the slow path, retest after 7.3 rather than assuming the old numbers still hold.
What changed in Zstd and why does a CPU probe matter?
Zstd was issuing repeated CPUID instructions to check for BMI2 support. CPUID is a serializing instruction, so calling it inside hot paths stalls the pipeline every time. Linux 7.3 probes once at boot and caches the answer. The reported result is 71 percent off decompression time and 18 percent off compression for crypto_acomp. Anything that leans on kernel side Zstd feels this: compressed Btrfs, zram, initramfs decompression and squashfs images.
When does Linux 7.3 actually ship?
Expect the final tag in the second half of October 2026, assuming the usual six or seven release candidates. Torvalds does not commit to a date, and a large merge window is the kind of thing that occasionally buys an extra rc. If you are planning a distribution rebase or a kernel qualification cycle, treat mid to late October as the earliest realistic point and start testing rc builds now on the workloads you care about.
Is it worth testing rc1 on real hardware?
On spare hardware and in virtual machines, yes, and this cycle more than most, because a lot of the new material is enablement for silicon that previously needed out of tree patches. That is exactly the code that benefits from being booted on machines the developers do not own. On anything carrying production load, no. Wait for at least rc4 and for your distribution to have taken a pass at it.