[Bug 1196438] New: Consider switching to 300HZ default
https://bugzilla.suse.com/show_bug.cgi?id=1196438 Bug ID: 1196438 Summary: Consider switching to 300HZ default Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs@opensuse.org Reporter: dmueller@suse.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- I recently stumbled over the 300 HZ option in the kernel configuration. Currently we are using 250 HZ with IDLE_HZ. The HZ setting is used as far as I can see to determine when jiffies are advancing, so it influences the granularity of a couple of things like kvmclock, timers and so on. Also USER_HZ is 100 HZ which is the granularity to which some metrics are exported to user space. 300 is divisible without remainder by 100, unlike 250. so it appears there are good reasons for switching the default, and it is "just" 20% more timer interrupts than before, so it should not be a huge issue. I also did a test build and a 300 HZ kernel is by a few bytes smaller than a 250 HZ kernel, indicating that the compiler can optimize away a few things. I am seeing an increase in a few small functions, and I'm looking into making the code size increase go away with a source level tweak. I've benchmarked both versions in a micro benchmark that does a billion invocations of both, and while the code is larger, it runs in exactly the same runtime (+/- 3% which I consider my benchmark noise level) on a Ryzen Zen 2+. In the Kconfig description of 300 HZ option, it appears this is more recommended for multimedia usecases because it is divisible without remainder for common rates, like 30 (fps), 60 fps , 120 fps, 44.1khZ and others that are often needed. This is imho not only usable for desktop, but also for servers that are using multimedia related applications. I've seen that fedora-like distributions use 1000 HZ, arch linux uses 300 Hz and debian defaults to 250 HZ. So there is no clear trend. I'd be fine with 300 or 1000 HZ. Comments? Would like to hear your feedback before sending a change to the Tumbleweed configs. -- You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1196438
Dirk Mueller
https://bugzilla.suse.com/show_bug.cgi?id=1196438
https://bugzilla.suse.com/show_bug.cgi?id=1196438#c1
--- Comment #1 from Dirk Mueller
https://bugzilla.suse.com/show_bug.cgi?id=1196438
https://bugzilla.suse.com/show_bug.cgi?id=1196438#c2
Mel Gorman
see https://lists.opensuse.org/archives/list/kernel@lists.opensuse.org/thread/ QN2AFMCXQGGHF2I6FSQYVH6AXRX4WPIQ/ for context
Battery of scheduler tests comparing HZ=250 (default x86-64 on master) versus HZ=300 will be queued in. Note that as the queue already has a substantial number of tests on it, it'll take several days before there are results to evaluate. -- You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1196438
https://bugzilla.suse.com/show_bug.cgi?id=1196438#c3
Mel Gorman
(In reply to Dirk Mueller from comment #1)
see https://lists.opensuse.org/archives/list/kernel@lists.opensuse.org/thread/ QN2AFMCXQGGHF2I6FSQYVH6AXRX4WPIQ/ for context
Battery of scheduler tests comparing HZ=250 (default x86-64 on master) versus HZ=300 will be queued in. Note that as the queue already has a substantial number of tests on it, it'll take several days before there are results to evaluate.
In general the performance results are not bad. There were a few outliers showing major regressions but they were not consistent across machines or clear that it was specifically due to a change in HZ and most likely noise (the benchmarks in question are not always consistent). The most obvious impact is the last surprising one -- more interrupts are delivered. As more CPUs become active for a workload that is scaling from 1 CPU to many CPUs, the interrupts increase relative to the number of CPUs in the system. This may generate a few bugs, particularly for systems where there are many active CPUs. However, it can be trivially checked by monitoring /proc/interrupts over time and checking if the increases are exclusively tick related. Overall, I think this is safe enough to enable. It'll generate some noise when/if SLE adopts it but it'll be manageable. -- You are receiving this mail because: You are the assignee for the bug.
https://bugzilla.suse.com/show_bug.cgi?id=1196438
https://bugzilla.suse.com/show_bug.cgi?id=1196438#c4
--- Comment #4 from Frederic Weisbecker
I recently stumbled over the 300 HZ option in the kernel configuration. Currently we are using 250 HZ with IDLE_HZ. The HZ setting is used as far as I can see to determine when jiffies are advancing, so it influences the granularity of a couple of things like kvmclock, timers and so on. Also USER_HZ is 100 HZ which is the granularity to which some metrics are exported to user space. 300 is divisible without remainder by 100, unlike 250.
so it appears there are good reasons for switching the default, and it is "just" 20% more timer interrupts than before, so it should not be a huge issue. I also did a test build and a 300 HZ kernel is by a few bytes smaller than a 250 HZ kernel, indicating that the compiler can optimize away a few things.
I am seeing an increase in a few small functions, and I'm looking into making the code size increase go away with a source level tweak. I've benchmarked both versions in a micro benchmark that does a billion invocations of both, and while the code is larger, it runs in exactly the same runtime (+/- 3% which I consider my benchmark noise level) on a Ryzen Zen 2+.
In the Kconfig description of 300 HZ option, it appears this is more recommended for multimedia usecases because it is divisible without remainder for common rates, like 30 (fps), 60 fps , 120 fps, 44.1khZ and others that are often needed. This is imho not only usable for desktop, but also for servers that are using multimedia related applications.
I've seen that fedora-like distributions use 1000 HZ, arch linux uses 300 Hz and debian defaults to 250 HZ. So there is no clear trend. I'd be fine with 300 or 1000 HZ.
Comments? Would like to hear your feedback before sending a change to the Tumbleweed configs.
I may be disappointing but I don't have a strong opinion on this. This was introduced in 2006 due to some frame rate frequency (https://lwn.net/Articles/208411/). Nowadays we have hrtimers for precise deadlines and dynticks for power consumption. In any case I don't mind either 250 or 300 Hz. Both are good tradeoffs. -- You are receiving this mail because: You are the assignee for the bug.
participants (1)
-
bugzilla_noreply@suse.com