[Bug 1226827] Switch to 1000Hz kernel timer frequency
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1226827 https://bugzilla.suse.com/show_bug.cgi?id=1226827#c3 Jiri Wiesner <jwiesner@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jwiesner@suse.com --- Comment #3 from Jiri Wiesner <jwiesner@suse.com> --- 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. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@suse.com