Linux 5.19 Looking Real Good On The HP Dev One, XanMod + Liquorix Also Tested

[phoronix]

Phoronix: Linux 5.19 Looking Real Good On The HP Dev One, XanMod + Liquorix Also Tested

With the very popular HP Dev One that is powered by an AMD Ryzen 7 PRO SoC and running Pop!_OS, a number of Phoronix readers inquired about seeing benchmarks of some of the alternative kernel flavors on the device. So here is a look at the stock Linux 5.17 kernel up against the Linux 5.18 and 5.19 (Git) kernels and then Liquorix and XanMod tossed in as alternative flavors running on the Pop!_OS 22.04 installation.

https://www.phoronix.com/vr.php?view=31280

[CochainComplex]

The uplift of 5.19 is quite substantial. Is there any particular reason? I see that DB workloads and FlexIO are quite impressive under 5.19. IIRC the usual performance difference of the kernel to kernel is not so much comparable of mainline to xanmod.

[oMoM]

I've been always curious about the performance of the amd-zen* kernels available in the AUR.
Given that this laptop has an AMD CPU, It would be enteresting to know how this or similar linux-friendly AMD laptops perform on those kernels compared to the kernels mentioned in the article. For a Linux desktop productive scenario ofc.

[reba]

Yay, great to see my impression of xanmod being a nice kernel now has some numbers to back up that feeling.
Looking forward to the xanmodded 5.19

Btw:
- which exact xanmod kernel is in use? "5.18.10-xanmod1"?
- is this with "5.18.10-xanmod1" or "5.18.10-xanmod1-x64v2"?

[CochainComplex]

Yay, great to see my impression of xanmod being a nice kernel now has some numbers to back up that feeling.
Looking forward to the xanmodded 5.19

Btw:
- which exact xanmod kernel is in use? "5.18.10-xanmod1"?
- is this with "5.18.10-xanmod1" or "5.18.10-xanmod1-x64v2"?

most likely Michael used the stable branch? which then is without x64v2 Flags.
I also can't wait for the xanmodded 5.19 Kernel

[damentz]

Regarding Liquorix results, I think there's three things happening here:

1. The CPU governor was changed for this test away from ondemand/performance to schedutil. Schedutil does not operate correctly on PDS/BMQ. Maybe next release I'll just remove it entirely: Liquorix 5.18: Scaling Governor: acpi-cpufreq schedutil (Boost: Enabled) - CPU Microcode: 0xa50000c. Years ago powersave was removed for the same reason, distributions were attempting to set powersave on acpi-cpufreq believing it was running intel-pstate. Obviously, this was a huge problem since it gave the illusion that Liquorix was running about 5-10x slower than stock or other kernels.
2. There appears to be some major regression with BFQ. In prior tests, BFQ did perform worse, but not to this degree if my memory is right. But considering the schedutil governor was used, core frequency scaling could be related and exaggerating the issue.
3. The futex/semaphore performance might be an indicator of some other misconfiguration, I'll look into what tunables might be causing PDS to score low here, but most likely schedutil didn't scale frequency properly with core utilization.

As a final note regarding all points above, you can see an anomaly in power usage in with Liquorix compared to all other kernels. The top end power usage is lower than all other kernels, indicating faulty core frequency scaling. Faulty core frequency scaling will slant all benchmarks, especially anything single threaded where schedutil notoriously does a bad job on with alternative schedulers.

[rfl1911]

I'm curious to see these kernels with:

Low mem + swap
mem=512mb/1gb/2gb to force swap

Latency with high I/O (opening some "heavy" programs(chromium/firefox with some JS (bellard's JS VM?), http://webglsamples.org/aquarium/aquarium.html while rsync kicking in the same storage(HDD/sata SSD/NVME SSD)

Wine with some multi threaded program

and the block schedulers: mq-deadline kyber bfq none

Another thing: mix these above ext4/xfs/another filesystem ( recently I changed to xfs and rsync in HDDs does not seems to disturb like ext4)

seems XanMod/Liquorix are optimised for low latency in mind and not throughput

[bug77]

5.19 is more about adding proper Alder Lake support. For some reason Michael felt like testing 12900k last week, using 5.18. And now he's showing us how 5.19 performs on Zen... We'll get there eventually.

[Linuxxx]

Regarding Liquorix results, I think there's three things happening here:

1. The CPU governor was changed for this test away from ondemand/performance to schedutil. Schedutil does not operate correctly on PDS/BMQ. Maybe next release I'll just remove it entirely: Liquorix 5.18: Scaling Governor: acpi-cpufreq schedutil (Boost: Enabled) - CPU Microcode: 0xa50000c. Years ago powersave was removed for the same reason, distributions were attempting to set powersave on acpi-cpufreq believing it was running intel-pstate. Obviously, this was a huge problem since it gave the illusion that Liquorix was running about 5-10x slower than stock or other kernels.
2. There appears to be some major regression with BFQ. In prior tests, BFQ did perform worse, but not to this degree if my memory is right. But considering the schedutil governor was used, core frequency scaling could be related and exaggerating the issue.
3. The futex/semaphore performance might be an indicator of some other misconfiguration, I'll look into what tunables might be causing PDS to score low here, but most likely schedutil didn't scale frequency properly with core utilization.

As a final note regarding all points above, you can see an anomaly in power usage in with Liquorix compared to all other kernels. The top end power usage is lower than all other kernels, indicating faulty core frequency scaling. Faulty core frequency scaling will slant all benchmarks, especially anything single threaded where schedutil notoriously does a bad job on with alternative schedulers.

I've come to the conclusion that BFQ is overall not worth it on SSDs, even S-ATA ones.

The hit to write performance in particular is just too high to justify its use.

Therefore I've just settled on Kyber for SSDs, which still provides good enough low-latency desktop interactivity even during high I/O-loads like extracting multiple archives.

The same also applies to schedutil of course, with the performance governor always being the only sane choice really.

[Vistaus]

Regarding Liquorix results, I think there's three things happening here:[LIST=1][*]The CPU governor was changed for this test away from ondemand/performance to schedutil.

Not sure what you mean by "changed away"? On my openSUSE, Liquorix uses schedutil by default.