5 ms·

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

26 points by scns 3y ago

charcircuit 3y ago
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.
- jeffbee 3y ago
  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.
  - wharvle 3y ago
    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.
    - eitland 3y ago
      Where would you recommend that someone goes to look to learn how the BeOS scheduler works?
      - viraptor 3y ago
        https://www.haiku-os.org/ https://www.haiku-os.org/
        eitland 3y ago
        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.
  - charcircuit 3y ago
    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.
    - jeffbee 3y ago
      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.
  - lathiat 3y ago
    macOS on Apple Silicon does exactly that: https://eclecticlight.co/2022/10/13/making-the-most-of-apple-silicon-power-3-controls/ https://eclecticlight.co/2022/10/13/making-the-most-of-apple... https://eclecticlight.co/2022/01/07/how-macos-controls-performance-qos-on-intel-and-m1-processors/ https://eclecticlight.co/2022/01/07/how-macos-controls-perfo...
  - viraptor 3y ago
    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.
- mustache_kimono 3y ago
  > 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.
  - charcircuit 3y ago
    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.
    - mustache_kimono 3y ago
      > 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."
  - charcircuit 3y ago
    There could be a sysctl to control this even.
- viraptor 3y ago
  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.2freebsd.html 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.
deleted 3y ago
[deleted]
techbro92 3y ago
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.
- oynqr 3y ago
  These tests were made to see where throughput decreases with the rt kernel.
a-french-anon 3y ago
Was discussed before these (mostly throughput) benchmarks in https://news.ycombinator.com/item?id=39173229 https://news.ycombinator.com/item?id=39173229
m463 3y ago
> 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?

26 points by scns 3y ago

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.

jeffbee 3y ago
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.
- wharvle 3y ago
  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.
  - eitland 3y ago
    Where would you recommend that someone goes to look to learn how the BeOS scheduler works?
    - viraptor 3y ago
      https://www.haiku-os.org/ https://www.haiku-os.org/
      - eitland 3y ago
        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.
- charcircuit 3y ago
  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.
  - jeffbee 3y ago
    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.
- lathiat 3y ago
  macOS on Apple Silicon does exactly that: https://eclecticlight.co/2022/10/13/making-the-most-of-apple-silicon-power-3-controls/ https://eclecticlight.co/2022/10/13/making-the-most-of-apple... https://eclecticlight.co/2022/01/07/how-macos-controls-performance-qos-on-intel-and-m1-processors/ https://eclecticlight.co/2022/01/07/how-macos-controls-perfo...
- viraptor 3y ago
  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.
mustache_kimono 3y ago
> 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.
- charcircuit 3y ago
  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.
  - mustache_kimono 3y ago
    > 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."
- charcircuit 3y ago
  There could be a sysctl to control this even.
viraptor 3y ago
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.2freebsd.html 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.

deleted 3y ago

[deleted]

techbro92 3y ago

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.

oynqr 3y ago
These tests were made to see where throughput decreases with the rt kernel.

a-french-anon 3y ago

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

m463 3y ago

> 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?