I am running Boinc with Einstein@home.
Their benchmark floating point and integer MIPS are 3 to 4%
faster when running the Debian 3.0 kernel than when running
your 3.0 amd64 liquorix kernel.
It looks like the improvement of the responsiveness and interactivity goes at the cost of some calculation speed.
Any idea why liquorix seems to perfom somewhat slower?
Back to top

My guess is the difference between CFS and BFS. Usually I don't mind it being a little slower if it's more responsive. I end up getting a much better user experience.
Back to top

Pedro's right, the Liquorix has more context switches to retain higher responsiveness for desktop systems. If you really need the throughput, you can always adjust the rr_interval under /proc/sys/kernel/ and use a sysctl entry in /etc/sysctl.conf to make your change permanent.

Remember, higher rr_intervals equate to more throughput but less general latency. You may find that you don't even notice the difference, and in that case, that's good! Raise it until you get your desired performance in boinc.
Back to top

I tried rr_interval values of 3, 30, 300 and 3000.
There was no noticeable increase of the benchmark floating point and integer MIPS.
Back to top

Ah! That's good that the rr_interval doesn't seem to matter. So the context switches are not interfering with throughput as much as one would think.

However, there are more new benchmarks of BFS here: www.phoronix.com/scan.php?page=article&item=bfs_two_years

As you can see, BFS simply scores better on different benchmarks. If you follow Con's philosophy, boinc is not the type of application BFS was designed to improve performance on. Any process scheduler should be able to use their idle cycles without damaging the latency of non-idle class processes. BFS, however, strives for very low latency desktop centric work, which means less CPU bandwidth in the idle class in order to retain low latency on the tasks that really matter.

If this workload really matters to you, you can bring it up with Con in #ck @ irc.oftc.net.
Back to top

Hi, just a guess/point. Liquorix isn't compiled with size optimization (last time I've checked), and according to Linus "Kernel" Torvalds himself, this optimization does more than decreasing the final size, it also produces some performance gains. I'm not sure that's the reason why, it's just a potential factor as we're speaking of a difference that is observed between kernels with and without size optimization. But there is the whole rest of the stuff that differs as well.

yarchive.net/comp/linux/Os.html
Back to top

Compiling with -Os used to create better code when we used the 3.x branch of gcc. This is not true anymore with modern versions of gcc where -O2 tends to always create a better compiled file than -Os.

I did benchmarks myself, and optimizing for size lead to a performance regression, but it was immeasurable to the naked eye if you didn't have any precise instruments or tools to determine throughput on a linux box.

Confirm it yourself and try recompiling the kernel.
Back to top