Linux 7.3-rc1 closed the merge window on 30 August. Linus Torvalds highlighted its size, including a large AMD graphics contribution. Neither line count nor the number of merged commits tells you how much faster your machine will run.
What the release message actually measures
In the release mail, Torvalds describes a large first release candidate without claiming an exact second-place ranking. He attributes roughly a third of the patch to AMD graphics code and the DCN6 register-header contribution. The illustration translates that approximate proportion into a simple area comparison; it is not our own count of changed lines.
A hardware register definition can add many lines without adding a path used on your computer. Conversely, a tiny scheduler change can alter behaviour on hardware you already own. Patch size, supported hardware and workload performance answer different questions.
Build a useful comparison
Pick one symptom or workload before testing. For a suspend problem, record whether the machine wakes, whether the display returns and whether networking reconnects. For a storage workload, hold dataset, filesystem, mount options and cache state constant. For a game, keep resolution, graphics settings and driver userspace fixed. A mixture of unrelated benchmark percentages cannot predict the result.
Use a test machine or recoverable installation with a known-good boot entry. Keep a copy of important data outside it. Record the previous kernel and the candidate actually booted, plus firmware and any third-party modules. These commands inspect the current system without changing its configuration:
uname -a
cat /proc/sys/kernel/taintedThe first identifies the running build. A nonzero taint value is a bitmask describing conditions relevant to debugging; it does not automatically prove that the hardware is defective or explain a regression.
Turn a failure into a report
The kernel’s issue-reporting guide explains checking current upstream code, documenting reproduction and identifying the last working version. Follow its subsystem-routing guidance rather than sending an unexplained full log to a random maintainer.
A useful report starts with four concrete facts: the action, expected outcome, observed outcome and the kernel where behaviour changed. Attach relevant logs after reviewing them for private data. If a fault only occurs after ten suspend cycles, say so; a single successful wake does not contradict it. Repeating the same sequence on both builds is more valuable than changing several drivers at once.
This remains an account of rc1, not an announcement that Linux 7.3 is stable. The historical publication date is preserved while the explanation is corrected.
Sources
Reviewed Torvalds’ release mail; removed unsupported exact ranking and mixed subsystem performance claims, and added a reproducible regression-reporting plan.