On Thu, 24 Feb 2022 10:30:07 +0100, Jiri Slaby wrote:
Hi,
On 23. 02. 22, 17:09, Dirk Müller wrote:
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.
Unlike today still common 25 fps (PAL) and 48kHz.
Heh, we need a kernel flavor per location? :)
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.
Even 1 kHz might be fine on some archs with NO_HZ_IDLE. But does it bring anything while having hrtimers?
That's my question, too. And, we have enable dynamic preempt, so the kernel can run in full preemption if user wants better latency...
Historically, you wanted the lowest good value for power savings. And the highest possible for preemption (best user response feeling).
We even had 1kHz until: https://github.com/openSUSE/kernel-source/commit/50a275a4bca006566590e94f880...
The reasons to the change are not noted (again!), so we can only guess...
I actually don't care about what value is selected. But you should get in touch with timer guys and the performance team too. I doubt they read this list :). But they should definitely comment (provided we unify kernels with SLE). So maybe creating a bug?
Agreed, this is nothing but a performance tuning, and our experts can give better comments and evaluations. thanks, Takashi