The Intel 80486 was announced in 1989—the year the Berlin Wall fell, amid Japan's bubble economy. Compatibility code written for that chip left conditional branches in the Linux kernel's build configuration all the way until 2026.
With the release of Linux 7.1 on June 14, 2026, the Time Stamp Counter (TSC) on x86 processors became a mandatory boot requirement. The commit "x86/cpu: Make CONFIG_X86_TSC unconditional" (111cbb45) was part of a 15-patch series that Ingo Molnar submitted as an RFC in April 2025, and it was merged into the tip tree's x86/cpu branch on May 30, 2026. With this, the very option of building the kernel for x86 CPUs lacking a TSC has disappeared.
The TSC is a 64-bit register that counts the clock cycles elapsed since the CPU was reset. Introduced with the original Pentium in 1993, it is read via the RDTSC instruction. Every modern Intel and AMD processor has one. The problem was that pre-Pentium chips—that is, the i486 and some compatible CPUs—lacked this register entirely, and even after the Pentium's introduction, clones such as the Cyrix 6x86 either lacked a TSC or treated RDTSC as an illegal instruction.
A Decision Windows Made Over a Decade Earlier
Microsoft settled the question of how to handle the TSC far earlier than Linux did.
When Windows 2000 and Windows XP introduced the high-resolution performance counter API QueryPerformanceCounter (QPC), the TSC was considered unreliable, and Windows relied on the motherboard's HPET timer or the ACPI PM timer as the basis for QPC. The turning point came with Windows 7 (2009): on systems with a constant-rate TSC, Windows began adopting the TSC as the basis for QPC. By Windows 8 and Windows Server 2012 (2012), the TSC had become the standard basis for QPC.
This decision was backed by a clear performance gap. According to Microsoft's official documentation, TSC-based QPC reads complete in tens to hundreds of CPU cycles. Falling back to a motherboard platform timer, on the other hand, pushes read costs up to roughly 0.8–1.0 microseconds. The TSC can be read directly from a CPU register, avoiding kernel transitions, whereas HPET and PM timers require access via memory-mapped I/O, which also constrains scalability under concurrent calls.
| Item | TSC-based | Platform timer (HPET/ACPI PM) |
|---|---|---|
| Read latency | Tens to hundreds of CPU cycles | ~0.8–1.0 microseconds |
| Access method | Direct CPU register read (RDTSC/RDTSCP) | Memory-mapped I/O |
| Kernel transition | Not required (readable directly from user mode) | Required |
| Concurrent access | Independent per core, no contention | Shared resource, limited scalability |
| Adoption in Windows | Phased in from Windows 7 (2009), standardized in Windows 8 (2012) | Used as QPC basis in Windows Vista/Server 2008 |
The reason Linux couldn't make the same assumption was that the kernel continued supporting hardware dating back to the i486 era. Code that branched at build time on whether a TSC existed, falling back to a different timer when it didn't, was maintained for more than 30 years.
One Remark from Linus Ended 30 Years of Compatibility Code
In April 2025, Linus Torvalds wrote on the kernel mailing list:
"I really get the feeling that it's time to leave i486 support behind. There's zero real reason for anybody to waste one second of development effort on this kind of issue."
Following this remark, x86 subsystem maintainer Ingo Molnar drafted a 15-patch series titled "x86: Remove support for TSC-less and CX8-less CPUs." The series consists of five stages:
- Removing the M486/M486SX/ELAN CPU options and their Kconfig dependencies
- Removing support for TSC-less M586 variants (some variants of the original Pentium)
- Removing support for TSC-less clone CPUs such as UMC, WinChip, and RDC321X
- Making CONFIG_X86_TSC unconditional and simplifying TSC-related build-time branches
- Making CONFIG_X86_CX8 (the CMPXCHG8B instruction) unconditional as well, and removing the associated fallback code
The fourth item is today's commit. The change itself is small—3 files, +1/-3 lines. It removes the enumeration of CPU models (MWINCHIP3D, MCRUSOE, MEFFICEON, MCYRIXIII, MK7, MK6, MPENTIUM4, and others) that had made TSC conditional in the Kconfig depends on clause, and enables it unconditionally with just def_bool y. The substantive change happened earlier: Linux 7.0 (released April 12, 2026) removed i486 support, and during the 7.1 development cycle, support for early Pentiums and clone CPUs lacking a TSC also disappeared. Only once the assumption that a TSC is "always present" could be made did this three-line change become possible.
Molnar notes in the commit message that "this is just removing the Kconfig glue—removal of the now-unnecessary !X86_TSC code will be done in a separate patch." In other words, dead code premised on the absence of a TSC still remains in the kernel source and will be removed gradually in future releases.
Twenty Years Before the TSC Became a "Usable" Timer
The history of the TSC is, in effect, the history of x86's struggle with power management.
On the original Pentium, the TSC's count advanced in lockstep with the CPU's actual clock frequency. When the CPU dropped its clock speed in a power-saving mode, the TSC slowed down accordingly; when Turbo Boost kicked in, it sped up. This made it useless for measuring wall-clock time. And once the multi-core era arrived, the problem of TSC values not staying synchronized across cores was added on top.
Intel introduced the constant-rate TSC (Invariant TSC) around the Core 2 era (circa 2006). The count advances at a fixed rate regardless of P-state or C-state transitions. AMD provided an equivalent feature starting with Family 10h (Barcelona/Phenom, 2007). This characteristic—verifiable via the constant_tsc flag in /proc/cpuinfo on Linux—is what turned the TSC into a reliable time source.
However, the kernel still had to support older CPUs that lacked a constant-rate TSC. Code for TSC calibration, reliability detection, and fallback in problematic cases had become overhead even on modern CPUs where the TSC is universally usable.
What the "Linux 7.0" Number Actually Means
As a side note, it's worth touching on the background of the version numbering. On February 8, 2026, Linus Torvalds announced that the next kernel release would be published as 7.0. This is not a major upgrade from the 6.x series—by the traditional convention, it would have been called 6.20. The bump in the major version number is simply a customary practice Linus follows whenever he feels "the number has gotten too big," with no technical discontinuity implied.
That said, 7.0 and 7.1 ended up marking a major milestone for x86 legacy support. i486 support was removed in 7.0, and the TSC and CX8 became mandatory in 7.1. According to reporting by The Register, Linux 7.1 removed over 140,000 lines of code, with further removals planned.
Code That Remains, and a Question That Doesn't Go Away
This commit merely changes the kernel's "assumptions." Fallback code written for TSC-less environments, cmpxchg8b_emu.S, which emulates CMPXCHG8B, and atomic64_386_32.S, which reproduces 64-bit atomic operations from the 386 era, are all still present in the source tree. Their removal is expected to proceed in future releases.
Another open question is how far this policy will go. In Debian, a proposal discussed in October 2025 would make x86-64-v2 (SSE4.2, POPCNT, and other features from the Nehalem generation of 2008 onward) mandatory starting with Debian 14 (forky), though no conclusion has been reached. In Fedora too, a change merging QEMU's requirement for x86-64-v2 has sparked debate over what baseline the distribution as a whole should adopt.
The kernel itself already requires SSE2, FXSR, and other features when building in x86-64 (AMD64) mode. Making the TSC mandatory is part of an ongoing effort to trim away 32-bit x86 legacy, and it has effectively no impact on users running 64-bit environments. The users affected are a small handful still running old kernels on 1990s-era embedded devices or industrial controllers. Molnar's patch series itself includes a note stating that "real users should not be affected, and legacy users can simply keep using older kernels."
The conditional branch for "the TSC might not exist," which the kernel had carried on its back for more than 30 years, vanished with a three-line commit. Technically, it's a small change—but it marks a significant shift in where x86 Linux draws the line on which era of hardware counts as "still in active use," moving that line from 1993 forward to 2008 and beyond.