Ubuntu Looking At Applying Low-Latency Optimizations To Its Generic Kernel

[phoronix]

Phoronix: Ubuntu Looking At Applying Low-Latency Optimizations To Its Generic Kernel

Ubuntu has long provided a "low-latency" kernel build intended for industrial embedded systems and other latency sensitive environments. Ahead of Ubuntu 24.04 LTS, Canonical is looking at applying those low-latency optimizations to their generic kernel build...

https://www.phoronix.com/news/Ubuntu-Low-Lat-Generic-Kernel

[indepe]

Enabling the low-latency settings in the generic kernel has been evaluated before, but it has been never finalized due to the potential risk of performance regressions in CPU-intensive applications (increasing HZ from 250 to 1000 may introduce more kernel jitter in number crunching workloads).

Well I'd have thought HPC / CPU-intensive workloads would be the first to take advantage of CONFIG_NO_HZ_FULL, thereby reducing jitter below that of a 250Hz kernel. (Even though that requires extra set up and specific privileges.)

[chromer]

Please include Arch kernel in benchmarks.

[perpetually high]

This would be great. I much prefer the low-latency config over generic for desktop usage.

I’ve been maintaining an Ubuntu kernel build script if anyone is interested. It builds a low-latency kernel and ignores the generic, as well as applying some custom patches and optimizations. It also includes those Ubuntu sauce patches and supports full tickless and rt kernels. Feel free to give it a whirl.

[KoenDG]

Maintaining a separate kernel for a single config option seems a bit overkill and it is a significant cost of engineering hours, build time, regression testing time and resources. Not to mention the risk of the low-latency kernel falling behind and not being perfectly in sync with the latest generic kernel.

Ah well there you go

[ms178]

I welcome any changes that improve the out-of-the box desktop experience if they don't cause meaningful regressions for some workloads.

[Volta]

Finally, but their excuses are stupid. There should be two kernels like in the past. One for desktop and another one for servers. Just build them with different configs. That's all.

Maintaining a separate kernel for a single config option seems a bit overkill and it is a significant cost of engineering hours, build time, regression testing time and resources. Not to mention the risk of the low-latency kernel falling behind and not being perfectly in sync with the latest generic kernel.

What BS is this? Low latency kernel is the mainline one, so how can it fall behind the latest generic kernel? Maybe only when Ubuntu goes with EOL kernel and supports it on their own. However, there's easy answer to this..

phoronix

The worry is primarily over risking HPC / server workload performance. But, hey, I invite that as an opportunity now to run some fresh Phoronix benchmarks of the Ubuntu kernel offerings in the coming days...

Would be great to see, but use the performance governor for more meaningful results, please.

[uid313]

How many Hz does Android, iOS, macOS, Windows and Windows Server have?

[ddriver]

Typical ... let's change kernel to change this one hardcoded parameter value. Cuz it is not like it can be made a dynamic value configurable value the user can set to their needs on a per use case.

How many Hz does Android, iOS, macOS, Windows and Windows Server have?

Android not many most likely - most android devices still can't do real time audio for example.

iOS in contrast has real time audio since day one, so I assume its pretty responsive, they took core audio for their mobile devices, quite possible other core internals were also brought over from macos.

Windows is barely ok, but the added bloatware often breaks realtime requirements

[MadCatX]

Typical ... let's change kernel to change this one hardcoded parameter value. Cuz it is not like it can be made a dynamic value configurable value the user can set to their needs on a per use case.

The length of a jiffy (= the internal kernel time unit) is derived from the CONFIG_HZ value. Conversions between jiffies and milliseconds are done with macros that, ideally, evaluate at compile time because the value of CONFIG_HZ is known. Making it adjustable might come with some performance penalty because the compiler would have less opportunities to optimize it. Additionally, we have had high resolution timers in the kernel for a very long time. Whenever the kernel needs to schedule something with sufficient precision, it will use those.