Ubuntu Generic vs. Low-Latency Linux Kernel Benchmarks For HPC & Desktop

[phoronix]

Phoronix: Ubuntu Generic vs. Low-Latency Linux Kernel Benchmarks For HPC & Desktop

With Ubuntu looking at applying their low-latency optimizations to their generic kernel builds in order to eliminate maintaining their existing "lowlatency" kernel option, I decided to run some fresh benchmarks looking at the performance impact of their low-latency kernel against their "generic" default kernel used on Ubuntu Linux systems...

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

[kozman]

These kind of synthetic benchmarks always prove the point that only in real-world---and, likely, very niche---use cases would the low-latency kernel yield perf wins over generic kernel. Still interesting to see. Thanks Michael.

[Volta]

Thanks for the benchmarks!

[mibo]

What is "low latency" about? It means that your important job is not significantly delayed by other jobs running on the cpu. (back then, using my floppy disk drive made my Linux system nearly unusable, because it brought everything to halt - added a huge latency)
Is there even one benchmark that checks for this latency?
I think, there must be a latency measurement running all the time and then the benchmarks run in the background. And, the important number is then - what is the latency with the heavy background load.

I still appreciate the benchmarks because they show, how much performance penalty the "low latency" kernel adds to the benchmarks. But, those benchmarks do not show what the "low latency" kernel is good for and if it actually does its job well...

[arighi]

Hey Michael, Andrea here (the guy who is proposing to merge the lowlatency settings into generic). Thank you so much for sharing this. I was planning to run the Phoronix test suite and get some numbers, and I will still do. I also want to using some tracing tools (bpftrace) to measure exactly how much time is spent in the tick handler with lowlatency vs generic, just to see if we are actually adding some overhead in the handler itself. Another nice things that I've been told is that HZ=1000 seems to help also to save power, because the CPUs can enter faster in the idle states (this is also something that I'm planning to test and measure).

Anyway, it's really nice to see that somebody else is also contributing to this, so I just wanted to say thanks.

[sophisticles]

Low latency kernels are not for throughput improvement, they're for responsiveness.

[ddriver]

Low latency kernels are not for throughput improvement, they're for responsiveness.

You actually have to sacrifice latency for throughput - taking the time to schedule better. Most software doesn't have real time requiremnets.

Audio, signal processing, control systems and probably - largely - military applications - now that stuff benefits from real time.

Remember, one day all Terminators will probably be FOSS compliant

[Michael]

What is "low latency" about? It means that your important job is not significantly delayed by other jobs running on the cpu. (back then, using my floppy disk drive made my Linux system nearly unusable, because it brought everything to halt - added a huge latency)
Is there even one benchmark that checks for this latency?
I think, there must be a latency measurement running all the time and then the benchmarks run in the background. And, the important number is then - what is the latency with the heavy background load.

I still appreciate the benchmarks because they show, how much performance penalty the "low latency" kernel adds to the benchmarks. But, those benchmarks do not show what the "low latency" kernel is good for and if it actually does its job well...

This testing is intended on looking not at the LL kernel benefits but rather workloads that may be aversely impacted if LL changes are applied to generic kernel.

[Michael]

Hey Michael, Andrea here (the guy who is proposing to merge the lowlatency settings into generic). Thank you so much for sharing this. I was planning to run the Phoronix test suite and get some numbers, and I will still do. I also want to using some tracing tools (bpftrace) to measure exactly how much time is spent in the tick handler with lowlatency vs generic, just to see if we are actually adding some overhead in the handler itself. Another nice things that I've been told is that HZ=1000 seems to help also to save power, because the CPUs can enter faster in the idle states (this is also something that I'm planning to test and measure).

Anyway, it's really nice to see that somebody else is also contributing to this, so I just wanted to say thanks.

I can run some CPU power numbers as well, hadn't thought about the 1000Hz impact prior. Setting PERFORMANCE_PER_SENSOR=cpu.power ./phoronix-test-suite benchmark .... will generate performance-per-Watt metrics too for the CPU for each benchmark. (assuming you are benchmarking as root or chmod /sys/class/powercap/intel-rapl* so the values can be read)

[CochainComplex]

Classic old Phoronix Topic

low lat vs generic

low lat = more responsiveness / sacrifice throughput
generic = more throughput / sacrifice responsiveness

pick your poison