Bugzilla – Bug 1226827
Switch to 1000Hz kernel timer frequency
Last modified: 2024-06-28 07:44:54 UTC
This would be optimal for desktop usage, gaming, music production, and maybe some servers, potentially making these workloads more responsive, performant and power-efficient on Tumbleweed instead of the current default of 300Hz. Consider the rationale and additional kernel configuration posted here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2051342 https://discourse.ubuntu.com/t/enable-low-latency-features-in-the-generic-ubuntu-kernel-for-24-04/42255 https://github.com/ValveSoftware/SteamOS/issues/1522 As far as I know, Android, ChromeOS, and Ubuntu have done this change
Tossing to performance team.
The last time this was discussed it reached the conclusion that while some low latency sensitive applications may benefit from the change, it comes at the cost of additional overhead processing the additional interrupts while CPUs are active. It comes down to a definite cost being incurred but onlyo a chance that an application is running that benefits. It may be suitable as a separate kernel flavor but the chances of regressions on the default kernel exists if HZ is increased to 1000.
When it comes to latency and responsiveness preemption is of more importance than the HZ value. An example that I have seen: It is not uncommon to have syscalls spend tens of milliseconds in kernel mode on a busy production system (e.g. a large machine running kubernetes and containers). The kernel may very well mark a task currently executing a syscall to be rescheduled (on account of a timer interrupt and the time slice assigned to the task running out) but it cannot not make a context switch until the syscall has finished executing under a non-preemptive kernel. Passing preempt=voluntary or preempt=full to the kernel will allow the kernel to react much faster. So, the ability of the scheduler to react to the NEED_RESCHED flag and the tweaking of the default time quantum assigned to tasks is expected to have more of an impact that changing the HZ value. SUSE kernels have dynamic preemption enabled since SLES15 SP4 and have no preemption by default. Tumbleweed boots up with voluntary preemption by default. (In reply to nuts from comment #0) > https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2051342 See comment 15 on this page. It there a specific use case (or a benchmark) that you are aware of, perhaps your own? We could work on addressing this use case before we start taking steps that change an option that potentially decreases throughput? On the other hand, Tumbleweed is not deployed on production servers of SUSE's customers so I think there is more leeway in terms of performance regressions.
(In reply to Jiri Wiesner from comment #3) > It there a specific use case (or a benchmark) that you are aware of, perhaps > your own? We could work on addressing this use case before we start taking > steps that change an option that potentially decreases throughput? On the > other hand, Tumbleweed is not deployed on production servers of SUSE's > customers so I think there is more leeway in terms of performance > regressions. I'm thinking of general desktop usage, gaming, and power efficiency, mostly. There should be improved response times in those cases and they *should* be more power efficient because the CPU enters an idle state faster, and there's a large gaming audience on Tumbleweed so far. According to the Ubuntu benchmarks I sent before, the nohz_full boot option could mitigate worse throughput, right?