Google engineer Qais Yousef released a patch on Sunday proposing to increase the Linux kernel's default timer frequency from 250Hz to 1000Hz. The Google engineer believes that the current Linux kernel default frequency can cause problems with scheduler decisions, such as imprecise time slices, load balancing delays, statistics update delays, and other related issues. QaisYousef believes that it is better for the kernel to adopt a default frequency of 1000Hz:

"A common screen configuration like Android and desktop systems is 120Hz. This gives the task 8ms to work on. 4ms is half that time, making the burden of making very good decisions on wakeup heavier than necessary. It also makes it harder to utilize the system efficiently to maintain optimal performance/watt. For example , we try to define the DVFS headroom as a function of TICK because it defines the worst case scenario for updating statistics. A larger TICK means that we have to increase the frequency too aggressively if we want to ensure that performance is not affected, but if the task does not exhaust all fragments, we lose the opportunity to use a lower frequency and save power.

In general, workload deadlines are getting shorter, and this is not unique to the UI pipeline.

I believe HZ_250 is the default setting as a trade-off for battery power in devices that may not like frequent TICKS that may drain the battery unnecessarily. But from what I understand, the current NOHZ status should be enough to alleviate these concerns. The recent addition of RCU_LAZY further helps maintain longer TICKs in idle scenarios.

As Saravana pointed out to me, a longer TICK does indirectly help timer cohesion, meaning it can mask problems with drivers/tasks requiring frequent timing, preventing entry into deeper idle states (for many systems, 4ms is a higher value that allows entry into deeper idle states). But it could also be argued that this is the problem with these drivers/tasks.

Faster TICK may still result in higher power, but not due to TICK activity. The system is more responsive (as expected) and dwells at higher frequencies are expected to be higher since they are accidentally stuck at lower frequencies. The series in [1] attempt to improve the scheduler's handling of response speed and provide users/applications with ways to better suit their needs, including opting out for adequate response (in the above series, ramup_multiplier is 0)"

Linux kernel timer frequency has long been a source of debate and differing opinions. But now the core default frequency is 1000Hz instead of 250Hz, which seems logical.

A patch to change the default frequency is now submitted for review/discussion.