Running Ubuntu 12.04 With The Liquorix Kernel

[phoronix]

Phoronix: Running Ubuntu 12.04 With The Liquorix Kernel

After performing a fresh Linux installation, most users are concerned with customizing their desktop or application set for their needs, but an increasing number of enthusiasts tend to be looking at their kernel. The Zen kernel was once very popular, but of increasing popularity amongst die-hard Linux enthusiasts is the Zen-related Liquorix kernel. While it claims to offer superior performance for common workloads, is this really the case? Here are some benchmarks of the stock Ubuntu 12.04 kernel versus the 3.2 kernel offered by Liquorix.

http://www.phoronix.com/vr.php?view=17195

[brad-x]

Kernels weren't packaged and patched by some kid and given an infantile label, and it certainly wasn't newsworthy - folks would evaluate, patch and build their own kernels.

This article treats a kernel change under Ubuntu, largely a free software environment with an open development community, a lot like a kernel change on an Android phone, a far more restrictive environment.

If the operating system you're using makes it so difficult to alter or replace your kernel that you must rely on others, you may want to re-evaluate the choices you've made.

[russofris]

I am not sure that I would promote the adoption of a BFS-enabled-kernel for general desktop use. My understanding is that BFS is a global-runqueue scheduler which does not scale in terms of throughput, but maintains low latency in a worst-case application profile. I believe that we already understand the behavior and the solution that BFS implements, and that the solution cannot be used to improve the main CFS scheduler or lead to a new scheduler paradigm. BFS only makes sense in a situation where it fits a fairly static/tested profile where interactivity is desired. BFS does not fit for desktop use. For desktop use, we have "nice" and "sched_granularity_ns".

I do not know if I have an issue with this. People should use the fastest available technology for their circumstance. I can only hope that by promoting BFS that we are not needlessly allocating resources to a legacy tech at the expense of the promotion of emergent and scalable solutions which can be leveraged to improve the default scheduler (make /proc/sys/kernel/sched_granularity_ns dynamic and self adjusting?). I also do not want to see inexperienced users switching out kernels in situations where they should be using the CFS + "nice".

I guess that it comes down to: Let's stop promoting legacy solutions and start promoting the workarounds applicable to current tech. Development resources continue to work on new tech/solutions.

[DanL]

Kernels weren't packaged and patched by some kid and given an infantile label

Yeah, liquor -- how juvenile!...

folks would evaluate, patch and build their own kernels.

Rolling/configuring one's own kernel ceased to be fun after doing it about two times (at least for me).

If the operating system you're using makes it so difficult to alter or replace your kernel that you must rely on others, you may want to re-evaluate the choices you've made.

The last time I checked, Debian/Ubuntu does allow that, so WTF are you talking about? Your whole post is just a bunch of l33tist nonsense...

[Paradox Uncreated]

I am not sure that I would promote the adoption of a BFS-enabled-kernel for general desktop use. My understanding is that BFS is a global-runqueue scheduler which does not scale in terms of throughput, but maintains low latency in a worst-case application profile. I believe that we already understand the behavior and the solution that BFS implements, and that the solution cannot be used to improve the main CFS scheduler or lead to a new scheduler paradigm. BFS only makes sense in a situation where it fits a fairly static/tested profile where interactivity is desired. BFS does not fit for desktop use. For desktop use, we have "nice" and "sched_granularity_ns".

I do not know if I have an issue with this. People should use the fastest available technology for their circumstance. I can only hope that by promoting BFS that we are not needlessly allocating resources to a legacy tech at the expense of the promotion of emergent and scalable solutions which can be leveraged to improve the default scheduler (make /proc/sys/kernel/sched_granularity_ns dynamic and self adjusting?). I also do not want to see inexperienced users switching out kernels in situations where they should be using the CFS + "nice".

I guess that it comes down to: Let's stop promoting legacy solutions and start promoting the workarounds applicable to current tech. Development resources continue to work on new tech/solutions.

Agree with you one name, needlessness, and obscurity.
In this case, I think there even exists a "low-latency" kernel for ubuntu, easily leechable from apt-get. Or is that the long-maintenance version only? In any case, I think the person below will never understand much of the spirit behind linux, if he tired of compiling after a few tries.

Peace be with You.

[kraftman]

Agree with you one name, needlessness, and obscurity.
In this case, I think there even exists a "low-latency" kernel for ubuntu, easily leechable from apt-get. Or is that the long-maintenance version only? In any case, I think the person below will never understand much of the spirit behind linux, if he tired of compiling after a few tries.

Peace be with You.

The kernels you're referring to are easily achievable from ppa. It will be great to see some latency and throughput benchmarks, between them:

https://help.ubuntu.com/community/Ub...RealTimeKernel

[evolution]

Well, these results confirm what I've been saying in the BFS thread... For I/O-based tests, in most cases, BFS losses to CFS... For things that need faster latency / some heavy workloads (such as audio editing/simultaneous tasks), BFS really shows here that can be a better approach than CFS. What I find strange in these results is the performance decrease in the Core i7 platform with the liquorix kernel (maybe some of the liquorix patches give regressions in Core iX platforms?)... Furthermore, I'd like to know which CONFIG_HZ options are applied to both kernels, as I can almost assure you BFS doesn't like low HZ configs (such as Ubuntu's default CONFIG_HZ=100, which is more optimized for servers)...

Cheers

[Kano]

This incorrect. After i told U that the 32 bit kernels are using CONFIG_HZ=250 and the 64 bit ones used CONFIG_HZ=100 they fixed the config and use now CONFIG_HZ=250 everywhere.

[allquixotic]

The standard deviations on these tests (both for BFS and the stock kernel) tell me that the results are not reliable. This is even less scientific than the usual Phoronix benchmark, because drawing any conclusions from a graph with such a huge standard deviation is difficult, if not impossible. Basically you're pointing at the entire content of Europe and saying "the criminal is somewhere in there", when proper detectives will at least figure out which town he's in.

If you ran the benchmarks at these standard deviations for a couple dozen iterations, and plotted it on a scatter plot, you'd see a collection of dots that look something like "white noise" (random/chaotic/atmospheric data -- like what you used to see on an Analog TV set when it was not getting any reception). You can't draw any conclusions from that.

[evolution]

This incorrect. After i told U that the 32 bit kernels are using CONFIG_HZ=250 and the 64 bit ones used CONFIG_HZ=100 they fixed the config and use now CONFIG_HZ=250 everywhere.

Well, from what I know (from my CK kernel compilations), I remember that CK puts in its patch a string in the CONFIG_HZ=250 option, saying it's unoptimized for both servers and PCs (I bet there are rgressions with CK's patch with that HZ config, not sure... that he doesn't want to assume )... If you use a CK kernel, he recommends you to use 300Hz for laptops+power savings (and with CK's kernel you can really achieve a lot of power savings using that configuration), or 1000Hz if you're using a desktop/laptop (with dinticks enabled). I can almost assure you for normal "desktop" usage, in older computers, CK's BFS behaves slightly better than CFS...

Cheers