For the most part, Liquorix should always lose on throughput benchmarks. Most of Phoronix's benchmarks focus on those.
You can check the comments regarding a discovery that certain sched_yield configurations destroy performance on out-of-tree schedulers and was amended post benchmarking.
This however was using MuQSS, which was notorious for poor single thread performance. Liquorix now uses PDS which attempts to use all physical cores before deferring to SMT threads. This completely changes performance for lightly threaded workloads.
There's been no news-worthy benchmarks since Liquorix switched from MuQSS to PDS.
Anecdotal, but I noticed a lot better browser performance when switching to no I/O scheduler, "none". I also noticed that Linux wasn't trying to use most of my RAM for buff/cache.
> Maybe the extra responsiveness under heavy loads is slowing it down?
Probably. It's a basic tradeoff in multitasking. A process can be left in cache and run for hundreds of milliseconds at high efficiency. Or the kernel can constantly juggle contexts in and out quickly, wasting cycles to reduce the delay between time slices and (potentially) allow fast response.
Yes, exactly. Let's imagine you were running two processes on one core, a server and a video game.
The way to achieve the highest /average/ frame rate regardless of latency would be to pause the game for a good second, run the server, pause the server, run the game for a second, and repeat. This has much lower overhead than swapping between them perhaps 100 times a second. Except it's super laggy. Swap them out 100 times a second and the process only has to wait maybe 10 ms until it next executes and appears much less laggy, but total throughput decreases.
> Maybe the extra responsiveness under heavy loads is slowing it down?
Yes! Extra responsiveness is done by switching more often between tasks. This is not free, so throughput suffers. The linux kernel lists that as the downside of e.g. 1000Hz ticks (something the Liquorix kernel enables).
