Ubuntu Generic vs. Low-Latency Linux Kernel Benchmarks for HPC and Desktop | Hacker News Reader

Ubuntu Generic vs. Low-Latency Linux Kernel Benchmarks for HPC and Desktop

phoronix.com

26 pointsscns19 comments

I skimmed through the tests in the benchmark and it seems like they’re testing based on throughput and I didn’t see any tests specifically to measure latency. It would have been really useful to see that.

These tests were made to see where throughput decreases with the rt kernel.

Was discussed before these (mostly throughput) benchmarks in https://news.ycombinator.com/item?id=39173229

> Most of the differences were within the Stress-NG kernel micro-benchmarks, which is to be expected.

"to be expected" with no explanation.

What makes this benchmark perform so poorly with the rt kernel?

If the system could detect when low latency is important they could get away with a single kernel. Or even simply enable low latency by default for the desktop version of ubuntu.

Why aren't modern systems just statically divided up, with known throughput-oriented junk homed on "efficiency cores" and known latency-sensitive tasks isolated on "performance cores", where each class of CPUs can use an optimal thread scheduler for its tasks? I know thread scheduling isn't the only thing users of lowlatency want, but I bet it solves the bulk of interactivity issues for desktop users.

How’d the BeOS scheduler work? Every desktop OS should just copy that. It felt like magic. Only thing I’ve seen since that even comes close is iOS, and it cheats by killing programs left and right (and has lost a little ground on that front over the years, anyway).

QNX Photon wasn’t far off but was never a realistic option for an everyday desktop (even less so than BeOS, which was at least intended as such).

Yeah, just copy BeOS.

Where would you recommend that someone goes to look to learn how the BeOS scheduler works?

https://www.haiku-os.org/

That far I was able to get by myself ;-)

I was wondering if someone had a good link to a book or paper or blog or something.

Why not just give the latency sensitive processes a higher priority than those that aren't? If there are extra cycles on the latency sensitive cores you wouldn't want them to be idling. Trying to outsmart the scheduler can lead to worse scheduling so you have to measure the real world performance.

You can't just wave your hands about having a scheduler that magically optimizes throughput and also promptly switches to a low-latency task as soon as it becomes runnable. There isn't one, because the way of sending the low-latency task to the CPU right away costs the throughput task some of its time.

macOS on Apple Silicon does exactly that: https://eclecticlight.co/2022/10/13/making-the-most-of-apple... https://eclecticlight.co/2022/01/07/how-macos-controls-perfo...

You actually want the opposite for power saving. (Sometimes) Pipewire got a change recently from Asahi Linux to ensure that relatively rare audio interrupts don't wake up the performance cores and are left on efficiency ones.

> If the system could detect when low latency is important they could get away with a single kernel.

I'm not sure this makes sense, especially in the context of modern power management. I mean -- even re: latency sensitive stuff, you probably don't want to be waking everything up at the granularity of a rt kernel.

If someone has a server and there are no humans interacting with it the the computer should realize that it is a good time to sacrifice latency.

> If someone has a server and there are no humans interacting with it the the computer should realize that it is a good time to sacrifice latency.

I think this is kinda the problem. Box: "Now is a good time to sleep for 1 ms." User: "Here I am and not so fast! This is supposed to be a rt kernel with a granularity of less than .002 ms."

There could be a sysctl to control this even.

The system doesn't have to detect it the processes themselves are able to describe this: https://manpages.ubuntu.com/manpages/trusty/en/man2/rtprio.2...

Even with that available, scheduling things optionally is not easy. You always sacrifice latency for throughput (or the other way around). Any gains across the board we keep getting in the base kernel from time to time.

Reply on news.ycombinator.com