A big kernel patch series was posted today by longtime Linux developer Thomas Gleixner. The set of 38 patches amount to some big time “spring cleaning” with addressing some code remnants still around that originated back in the very early Linux v0.1 kernel while some other code being cleaned up dates back to the Linux 1.3~2.1 kernel series from the 90’s.
Gleixner posted today a big tree-wide cleanup for addressing code “[ab]use” around the LATCH, CLOCK_TICK_RATE, and get_cycles() components. Gleixner explained of these little talked about antiquated code remnants still part of the Linux kernel:
“1) LATCH
The LATCH define goes back to Linux version 0.1 and has survived until today for the very wrong reasons.
Initially it was based on the x86 PIT frequency and also steered the timekeeping conversions.
With the arrival of non x86 architectures it got changed to be based on CLOCK_TICK_RATE in order not to change core code which depended on LATCH.
That all got meaningless when timers, timekeeping and scheduling infrastructure got rewritten more than two decades ago.
But there is still a lonely survivor in arch/x86/kernel/apm_32.c which dates back to Linux 1.3.46 (Dec. 1995)
Which causes the next historical gem
2) CLOCK_TICK_RATE
When Linux got expanded beyond i386 LATCH was made “flexible” by basing it on CLOCK_TICK_RATE to adjust for other frequencies than the i386 PIT frequency.
As LATCH this got meaningless long ago and for amusement value it got copied into new architectures arriving way after it got obsolete for no reason but with comments to the effect that it’s meaningless
And of course it had a lonely survivor in arch/x86/kernel/setup.c despite it being only an alias for PIT_TICK_RATE for a very long time.
3) get_cycles()
That was introduced in 2.1.133pre4 (Dec. 1998) to utilize the back then brand new TSC. The introduction broke everything except i386 SMP with a CPU having a TSC and got then fixed up within a couple of days with empty stubs returning 0 and #ifdeffery for CONFIG_TSC before the 2.2.0 release.
It’s amusing that the naming deliberately ignored that TSC is the acronym for Time Stamp Counter and not Cycle Counter and rather went for the underlying coincidence that the TSC was running at the same fixed frequency as the CPU core.
That turned out to be interesting when CPUs started to have frequency scaling as the TSC then turned into a variable frequency random number generator.
A decade later CPU designers came to senses and made the TSC invariant usually running at the nominal CPU frequency, which allowed to use it for reliable timekeeping purposes.
Non x86 architectures implemented get_cycles() based on whatever continuously running counter they had available in their CPUs. Some of them actual CPU cycle counters, but many of them running at a fixed frequency which was completely unrelated to CPU cycles.
Around 2004/5 the timekeeping subsystem was completely rewritten and made generic along with the scheduling clock and other related infrastructure. With that rewrite get_cycles() got mostly obsolete, but despite it being on the todo list of quite some people it never ceased to exist and it was just a conveniance vehicle to base other things like the recent addition of random_get_entropy() on top with a hideous #ifdef/#define macro maze.
The other remaining use cases are mostly debugging and testing code. Especially the usage in performance test code is [hilarious] at best. While the name get_cycles() suggests that it provides access to CPU cycles the reality is that it provides a unspecified counter for most systems, where a lot of architectures simply return 0 because they either do not have such a counter or did not bother to implement it at all.
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.
But the real solution is to remove it all together instead of proliferating the bogosity.”
Thus the big patch series goes on to remove the Linux kernel’s LATCH and CLOCK_TICK_RATE while consolidating and cleaning up other code, including the get_cycles() bits. The get_cycles() code is sticking around just for a couple of CPU architectures as just an architecture-internal implementation detail.
The big clean-up patch series can be found on the kernel mailing list.
