Page 1 of 2 12 LastLast
Results 1 to 10 of 13

Thread: Running Ubuntu 12.04 With The Liquorix Kernel

  1. #1
    Join Date
    Jan 2007
    Posts
    15,391

    Default Running Ubuntu 12.04 With The Liquorix Kernel

    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

  2. #2
    Join Date
    Mar 2012
    Posts
    1

    Default Back in my day...

    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.

  3. #3
    Join Date
    Jan 2009
    Posts
    466

    Default

    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.

  4. #4
    Join Date
    Oct 2007
    Posts
    1,308

    Default

    Quote Originally Posted by brad-x View Post
    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...

  5. #5

    Default

    Quote Originally Posted by russofris View Post
    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.

  6. #6

    Default

    Quote Originally Posted by Paradox Uncreated View Post
    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

  7. #7
    Join Date
    Oct 2010
    Posts
    257

    Default

    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
    Last edited by evolution; 03-27-2012 at 07:57 PM.

  8. #8
    Join Date
    Aug 2007
    Posts
    6,645

    Default

    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.

  9. #9
    Join Date
    Sep 2008
    Posts
    989

    Default

    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.

  10. #10
    Join Date
    Oct 2010
    Posts
    257

    Default

    Quote Originally Posted by Kano View Post
    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

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •