Ghosts from 1991? Out.
Thomas Gleixner — kernel veteran’s kernel veteran — dropped a massive tree-wide patch series today, targeting Linux 2026 Spring Cleaning by evicting LATCH, CLOCK_TICK_RATE, and get_cycles() abuses. These aren’t minor nits; they’re remnants from Linux v0.1, that bootstrapped hobby project Linus Torvalds announced on Usenet. And here’s the kicker: one survivor lurks in code from 1995.
Look, kernel devs have rewritten timers, schedulers, timekeeping — whole infrastructures — over two decades ago. Yet this junk persisted. Why? Backward compatibility on steroids, plus copy-paste sins across architectures.
Unearthing LATCH: A v0.1 Zombie
Gleixner lays it bare in his post. LATCH started as x86 PIT frequency, morphed for other arches via CLOCK_TICK_RATE, then became pointless post-rewrites.
The LATCH define goes back to Linux version 0.1 and has survived until today for the very wrong reasons. […] But there is still a lonely survivor in arch/x86/kernel/apm_32.c which dates back to Linux 1.3.46 (Dec. 1995)
That’s Advanced Power Management code, folks — pre-USB, pre-modern laptops. It’s hilarious, in a gallows way, that apm_32.c clung to this like a relic in a museum.
But wait. Gleixner doesn’t stop at history lessons. He rips out the defines, consolidates stubs, kills the macro mazes. get_cycles()? Demoted to arch-internal trivia for a few holdouts.
Short version: kernel slims down.
CLOCK_TICK_RATE’s Amusing Afterlife
This one’s a riot. Born to flex LATCH beyond i386, it lingered as PIT_TICK_RATE alias, then got blindly ported to new arches — complete with comments screaming “meaningless.”
Architectures arriving after obsolescence copied it anyway. Because devs gonna dev.
And get_cycles()? Introduced in 2.1.133pre4 for TSC fun, broke everything, got stubbed to zero. Name’s a lie — not cycles, just some counter (or zero). Gleixner nails it:
So in fact get_cycles() should have been renamed to get_bogo_cycles() long ago matching the BogoMIPS “impress your friends” printk which still exists for historical amusement value.
BogoMIPS. Remember that boot-time gag? This is its spiritual kin. Patches nuke most uses, leaving scraps for debug. No more random_get_entropy() propping it up.
Why Does Linux Hoard Like This?
Kernel’s modularity — blessing and curse. Layers accrete; no one’s paid to audit the basement. x86-centric origins mean non-x86 ports inherit warts. Two decades of rewrites bypassed these because… it worked?
My take? Linux’s success breeds complacency. FreeBSD excised similar junk years back; their tree’s leaner. Linux? A sprawling ecosystem where distros fear breakage. Gleixner’s series — 2026 merge window target — signals maturity. But it’ll take more Thomases.
Here’s my unique angle: this mirrors Windows NT’s kernel, still lugging 1993 VMS echoes in 2024. Microsoft’s paid billions to modernize; Linux does it volunteer. Prediction: post-cleanup, we’ll see fewer obscure bugs in edge-case timing. Not night-and-day perf, but reliability ticks up — vital for IoT, servers humming 24/7.
Does it matter for your desktop? Marginally. But in a world where kernels secure nations’ infra, every byte counts.
And yeah, corporate hype’s absent here — no Red Hat spin, just raw LKML truth. Refreshing.
Will Linux 2026 Spring Cleaning Boost Performance?
Directly? Nah. These defines were dead weight, not bottlenecks. No cycles saved on modern iron.
Indirectly — big yes. Cleaner code means fewer #ifdef hells for maintainers. New arches port easier. random_get_entropy() gets proper footing. Plus, it sets precedent: 2026 could spark a purge wave, targeting other fossils like old FPU stubs.
Data point: kernel size grew 20% yearly pre-5.x; cleanups reversed that. v6.12 sits at ~35M lines; trimming cruft keeps it sane.
Gleixner’s patches hit LKML — x86/apm_32.c gone, setup.c sanitized, get_cycles() neutered. Merge window’s months out, but trees are wide open.
So, enthusiasts, pull and test. Distro maintainers? Bless this man.
It’s not sexy. No AI hype, no crypto wars. Just code hygiene — the unsexy soul of open source longevity.
Why Hasn’t Kernel Cleanup Happened Sooner?
Blame inertia. Todo lists swelled; priorities went to features, security. get_cycles() hung on for “perf tests” — which returned bogus data anyway.
Architectural drag: kill on x86, but ARM? MIPS? They’d scream. Gleixner audited all, consolidated.
One para wonder: maintainers like him are rare gems.
Patch series lives here: LKML archive. Dive in; it’s a masterclass in kernel archaeology.
🧬 Related Insights
- Read more: Proving Presence with Crypto: A Flutter App That Locks Down Judicial Proofs
- Read more: VS Code 1.114 Delivers AI Chat Wins That Coders Actually Need
Frequently Asked Questions
What is Linux 2026 Spring Cleaning?
Thomas Gleixner’s patch series removing ancient LATCH, CLOCK_TICK_RATE, and get_cycles() code from the kernel, targeting 2026 merge.
Why remove LATCH from Linux kernel?
LATCH is a v0.1 relic, meaningless post-timer rewrites, surviving only in 1995 APM code — time to kill it.
Does Linux kernel cleanup improve speed?
Not directly, but cleaner code aids maintenance, ports, and cuts future bugs in timing subsystems.
