Neowin first highlighted the change as Linux “following Windows.” The kernel record and Microsoft’s own performance-counter documentation support the broad timing context, but the comparison needs a sharper line: Linux is making TSC presence an x86 boot-time assumption; Windows still treats TSC suitability as a runtime decision for its high-resolution timer API. Those are related engineering choices, not the same requirement.
The change appears in Linux 7.2’s documented x86 updates as part of a wider removal of support for TSC-less and CMPXCHG8B-less processors. Ingo Molnar’s patch series removes the Kconfig dependency that previously let CONFIG_X86_TSC vary based on selected old CPU targets. The resulting configuration is always enabled, because the remaining supported CPU baseline is now expected to include the counter.
Linux 7.2 closes a configuration path, not a timing fallback
A TSC is a register in x86 processors that increments as time passes and can be read with instructions such as RDTSC and RDTSCP. It is attractive for timing because reading a CPU register is much cheaper than consulting a motherboard timer such as HPET or the ACPI power-management timer.
But the phrase “TSC required” can be misleading. Linux 7.2 is not declaring every TSC reliable enough to be its system clocksource in every circumstance. The accompanying kernel discussion explicitly retains runtime TSC disabling. A machine can possess the instruction and register while still presenting a counter the kernel considers unsuitable for reliable timekeeping because of firmware defects, synchronization problems across processors, power-management behavior on old designs, or virtualization quirks.
That distinction is the central technical point missing from any simplified reading of the cleanup. The new requirement says an x86 CPU must have a TSC. It does not eliminate the kernel’s work of determining whether that TSC is stable, synchronized, and usable as a clocksource.
On ordinary modern desktops, laptops, and servers, this will not alter how Linux keeps time. A current Intel Core, AMD Ryzen, Xeon, or EPYC system was already far beyond this baseline. Nor should users expect a measurable speed-up from installing Linux 7.2: applications and the kernel could already use a suitable TSC where one was available. The gain is smaller and more durable—fewer build-time branches and fewer test combinations for code nobody using a normal contemporary PC encounters.
The code removal is bundled with a related decision to assume CMPXCHG8B, the 32-bit x86 instruction used to build 64-bit atomic operations. That matters more to kernel implementation than the TSC headline does. Historic Linux support for systems without that instruction required special atomic-operation handling and, in the broader series, helped preserve old emulation paths that contemporary maintainers rarely exercise.
The 486 cutoff arrived in Linux 7.1, not Linux 7.0
One factual detail in the supplied account is wrong: Linux 7.0 did not drop Intel 486 support. Linux 7.1 began that process in April 2026 by removing the Kconfig options used to build kernels specifically for i486-class processors, including the 486SX and AMD Elan selections. Independent reporting by Phoronix at the time described the change as the beginning of a phased retirement, and the project’s 7.1 history confirms that Linus Torvalds merged the initial removal.
That date matters because it explains why Linux 7.2 can make the TSC configuration unconditional. Linux 7.0 remained a viable upstream baseline for dedicated 486 hobby projects. Linux 7.1 removed the explicit build target, and Linux 7.2 follows through with more of the assumptions that the older target had prevented.
The transition also was not solely about the TSC. A conventional Intel 486 lacks CMPXCHG8B, while 486SX models lack an integrated x87 floating-point unit. Maintaining support meant retaining special-case code, including old software floating-point emulation and workarounds for atomic operations. The Linux kernel mailing-list series described the combined cleanup as removing more than 14,000 lines when the legacy math emulation code was included.
For retrocomputing users, the result is a clearer boundary rather than a surprise new hardware check on a modern distribution. Mainline Linux 7.2 is no longer a reasonable base for an unmodified i486 deployment. Existing long-term-support branches, vendor-maintained kernels, or an out-of-tree patch set remain the realistic routes for keeping those systems alive. The specialist work is already underway: developer David Gow has documented a Linux 7.1-oriented restoration path, but also warns that restoring i486 support will grow harder as further cleanup lands.
For enterprise administrators, this does not create an action item unless an organization has unusual 32-bit industrial, lab, or appliance hardware built around very old x86 silicon. Even then, the first question is not whether the device has a TSC; it is whether its distribution vendor intends to ship Linux 7.2 and whether its kernel configuration depended on the retired CPU target.
Windows chose the same fast counter differently
Microsoft has preferred the TSC for high-resolution timing on suitable Windows systems for years, but it did not turn the counter into an unconditional equivalent of Linux’s new x86 kernel baseline. Windows exposes QueryPerformanceCounter, or QPC, as the supported abstraction rather than asking applications to read RDTSC themselves.
Microsoft’s documentation says most Windows 7 and Windows Server 2008 R2 systems could use constant-rate TSCs for QPC where the operating system or hypervisor synchronized processor counters at initialization. Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 R2 expanded that approach with improved synchronization designed for larger multiprocessor systems.
The performance motivation is real. On an appropriate machine, a TSC-backed QPC query can be served in tens or hundreds of CPU cycles and often without a user-to-kernel transition. Platform timers cost more to access and are shared hardware resources, which can harm scalability when many cores request timestamps at once.
Yet Microsoft’s present guidance still tells developers not to call RDTSC or RDTSCP directly. The company warns that a raw TSC read may not be reliable on all Windows versions, across live virtual-machine migrations, or on hardware lacking an invariant and tightly synchronized counter. QPC exists to hide those distinctions and select a platform counter when Windows decides the TSC is unsuitable.
This is why “Linux follows Windows” is an imperfect headline. Windows standardized an API that may use the TSC. Linux 7.2 has standardized a build-time x86 CPU capability because it has abandoned processor targets that lacked it. Windows remains prepared to use alternatives for timing; Linux remains prepared to reject a present-but-bad TSC for timekeeping. Neither operating system has simply decided that all TSC implementations are equal.
What users and developers should do
Most people should do nothing. A current x86-64 Windows PC, Linux workstation, virtual machine host, or server has the required instruction and is unaffected by the removal of the configuration option. Distribution kernels have generally targeted hardware much newer than i486 for years, often dropping 32-bit x86 entirely or setting an i686-or-newer baseline.
Developers should take the release as a reminder to use the operating system’s timing interfaces rather than raw processor-counter reads. On Windows, that means QueryPerformanceCounter for high-resolution intervals and the appropriate precise time APIs when wall-clock synchronization is required. On Linux, it means the kernel’s clocksource framework and user-space clock APIs, which can account for the kernel’s runtime judgment about the TSC.
The systems that need planning are the odd ones: a legacy x86 appliance, a preserved manufacturing controller, or a retro PC deliberately kept on an upstream kernel. Linux 7.2’s TSC change is evidence that upstream mainline support has crossed another hard boundary. For everyone else, it is maintenance work delivered exactly as it should be: invisibly.
