Increased Linux kernel timer frequency delivers big boost in AI workloads

Linux kernel timer frequency raised from 250 Hz to 1,000 Hz — (Image credit: Shutterstock)

At the weekend, a Google engineer proposed raising the default Linux kernel timer frequency from 250 Hz to 1,000 Hz. Linux-centric tech site Phoronix has quickly stepped up and assessed what the change might mean to users with a suite of A/B testing. Spoiler alert: The most notable benefits were seen in AI LLM acceleration. Elsewhere, the differences might be considered within the margin of error of system benchmarking. System power consumption changes seen in the comparison were also minimal.

Let's recap the patch statement shared by Google engineer Qais Yousef on Sunday before looking at some measured impacts. As mentioned, Yousef's main thrust was to propose that the current Linux kernel default to a timer frequency of 1,000Hz. The reasoning behind the proposal was that Linux users would benefit from improved responsiveness and faster workload completion in general.

Yousef also thought that moving to 1,000 Hz would banish the 250 Hz-related issues with "scheduler decisions such as imprecise time slices, delayed load balance, delayed stats updates, and other related complications," reported Phoronix. Toward the end of his patch notes, the engineer openly pondered over system power consumption, assuming that "the faster TICK might still result in higher power."

Latest Videos FromTom's Hardware

Watch full video here:

Phoronix's beefy AMD Ryzen 9 9950X (16C/32T) system with 32GB RAM and a Radeon RX 7900 XTX graphics card was the A/B Linux kernel timer frequency testing test bed. We see the first set of tests for processing performance in Llama LLMs, measured in tokens per second. This is probably the greatest showcase for the move to 1,000 Hz, with benefits from the change edging into double figures. However, the Nginx web server also showed double-figure percentage gains in requests handled per second, benefitting more with more connections.

TOPICS

Mark Tyson is a news editor at Tom's Hardware. He enjoys covering the full breadth of PC tech; from business and semiconductor design to products approaching the edge of reason.

2 Comments Comment from the forums

bit_user

The article said:
Elsewhere, the differences might be considered within the margin of error of system benchmarking.
No. Margin of error should be like < 1%. Several other benchmarks had differences were well above that.
nginx had a case that benefited from the 1kHz tick rate by 8.6%.
Darktable had a case where 250 Hz was 7.5% faster.
A few others in the 2-3% range.
I've seen no compelling explanation for performance changes of such a magnitude. It's generally accepted that a faster tick rate just adds overhead, which is why the default is now 250 Hz and used to be even lower.

The article said:
Let's recap the patch statement shared by Google engineer Qais Yousef
You missed a key part of the explanation, which was right in the first paragraph:
"The larger TICK means we have to be overly aggressive in going into higher frequencies if we want to ensure perf is not impacted. But if the task didn't consume all of its slice, we lost an opportunity to use a lower frequency and save power. Lower TICK value allows us to be smarter about our resource allocation to balance perf and power."

Source: https://www.phoronix.com/news/Linux-2025-Proposal-1000Hz
Reply
mitch074

To my knowledge, current default configuration is for the kernel to be tickless on all but the boot CPU core - meaning that this setting should have very little impact on power consumption as only one core would be affected, and it's the busiest one anyway.
Still, that default would change the system wide interrupt being sent once every 3 000 000 cycles - that's equivalent to a Pentium III 750 running a 250 Hz tick.
Reply