Linux-zen; have you ever tested a different kernel then the default kernel?

(tom) #1


some days ago i tested zen kernel from arch linux and i was really surprised by the responsive- and smoothness, so i suggest you get a try:
there isn’t any risk and don’t forget update-grub.

$ sudo pacman -U
#version number will change

a smooth and responsive desktop system is something that we all desire and the zen kernel is a step in this direction maybe we can use it as default kernel because chakra is desktop orientated.
so far as i know is this unique at the linux distros and this will sharpen our profile as a responsive distro.

what do you think?

--- Virtual Memory Subsystem ---------------------------
Mem dirty before bg writeback..:  10 %  ->  20 %
Mem dirty before sync writeback:  20 %  ->  50 %

--- Block Layer ----------------------------------------
Block Layer Queue Depth........: 128    -> 512
Default MQ scheduler......: mq-deadline -> bfq

--- CPU Scheduler (CFS) --------------------------------
Scheduling latency.............:   6    ->   3    ms
Minimal granularity............:   0.75 ->   0.3  ms
Wakeup granularity.............:   1    ->   0.5  ms
CPU migration cost.............:   0.5  ->   0.25 ms
Bandwidth slice size...........:   5    ->   3    ms
Ondemand fine upscaling limit..:  95 %  ->  85 %

--- CPU Scheduler (MuQSS) ------------------------------
Scheduling interval............:   6    ->   3    ms
ISO task max realtime use......:  70 %  ->  25 %
Ondemand coarse upscaling limit:  80 %  ->  45 %
Ondemand fine upscaling limit..:  95 %  ->  45 %

source and

if you think it works and is a good idea please vote

(kepszlok) #2

I can confirm, it feels quite smooth and a it’s a bit faster than the default kernel. For example, loading complex sites on Firefox are a bit faster.

I tested zen on my Thinkpad T410, with an i5 M520 cpu. It’s not a mustang…

(Luca Giambonini) #3

I think that the real change here is:

Default MQ scheduler......: mq-deadline -> bfq

We use the default scheduler (cfq) in our kernel and bfq is not enable by default. BFQ can be enabled manually and you should see such performance improvement.

(kepszlok) #4

CFQ scheduler was a generaly good one for many years. But other distros like Endless OS are about to switch to BFQ, for a more smooth user experience. Endless-OS-Goes-BFQ

Is there any plans to use BFQ or an other newer scheduler by default in Chakra?

(Luca Giambonini) #5

No, there is no plans to use it, but any feedback is welcome. If BFQ really provides this advantages we can think to use it by default in Chakra. (I have to enable this scheduler again, and see the impact)

(tom) #6

bfq or cfq queued the IO but muqss or cfs queued the time slices for every process and this is the “real trick” from linux-zen.

the IO scheduler can you feel with heavy IO as example when you compile a project like the kernel with the wrong scheduler the system will be sluggish under normal circumstances you shouldn’t feel it.

MUQSS plan and queue and reduces the latency between the time slices on the cpu for every job and this is the reason why @kepszlok feel this:

it seems there are much room for improvements on your system^^
have you tried the zen kernel?

cpu scheduler:

IO scheduler:
apropos bfq

(Luca Giambonini) #7

no, but I will try to build a kernel with the MuQSS patches.

(tom) #8

you can get these patches here

so far as i know using linux-ck MUQSS and linux-liquorix
and linux-zen maybe its more comfortable to use one from these existing PKBBUILDS

(Luca Giambonini) #9

I’m building the kernel with the patches from

If all is fine I will push it to staging so you/we can try

(kepszlok) #10

Good news!

Is there a good kernel benchmark for testing the differencies? Just to factor out the placebo…

(Luca Giambonini) #11

Done, uploaded to [unstable]
You can install it with:
sudo pacman -U

If you have nvidia, then you have to use nvidia-dkms!

I have installed this kernel on my main PC, let’s see in the next days how does it work.

(tom) #12

there is a kcmd option to influence muqss

(kepszlok) #13

I did some testing with all 3 kernels using the phoronix-test-suite, and the results are quite intresting!

Kernel1: default Chakra kernel, uses CFQ sched. for IO
Kernel2: Chakra-CK kernel, uses CFQ sched. for IO
Kernel3: Arch ZEN1 kernel, uses BFQ sched. for IO

I see both “upgraded” kernels are now in “extra”, so the proper way to install our CK kernel is:

sudo pacman -U

And for ZEN1 kernel:
sudo pacman -U && sudo update-grub

The results:
My pc: RyZen 2600 (6C/12T) running in fixes 4.15GHz all cores, with 16GB 3066MHz CL14 ram, SSD.

Kernel build time in seconds, less is better:
Default kernel: 121,77
Chakra-CK1: 115,5
ZEN1: 121,81

X265 video encode in fps, more is better:
Default kernel: 7,53
Chakra-CK1: 7,57
ZEN1: 7,53

7Zip encode in MIPS, more is better:
Default kernel: 35679
Chakra-CK1: 36619
ZEN1: 36072

My opinion
Our CK1 patched kernel is clearly the winner here, we shoud implement this asap! :slight_smile:
I did not tested UI responsiveness at this time, but that shoud be done in a much slower pc to get some real differences.

Possible other kernel improvements
Check out these results:

OMG! Clear Linux did simply rules the x265 results. They are using a bunch of optimization when building their packages. We may be able to use some of their methods. Details: Trying To Make Ubuntu 18.10 Run As Fast As Intel’s Clear Linux

Building the kernel
There may be an other way to improve our kernel’s performance. (i hope i’m still up-to-date in this) By default, the kernel are built with -O2 in GCC, withouth LTO (link time optimization) but these cab be changed in kconfig.

-O2 means that GCC will use all possible optimization, except the ones that may cause bigger image size and except the LTO. Since we are using the kernel in desktop systems, the size of the image did not at all important. We can try build it with -O3, that will enable all possible optimization, except LTO.

We can also experiment with LTO, that can result in some meaningfull reduction in the number of syscalls and image size. The LTO’s downside is it’s making harder / impossible to debug the kernel (i think it’s not an issue for us).
some older info about LTO-ing the kernel

(tom) #14
  1. the kernel that almack had build isn’t with ck1-patchset but with MuQSS and the improvement should be responsiveness. the patch sets are different settings for KVM and scheduling policys
  1. size is always a big problem because it must be read and copied to RAM, these actions costs a lot of time for reading and copy to RAM

(kepszlok) #15
  1. This is the name of his kernel.
    $ uname -a
    Linux kepsz-pc 4.18.12-2-ck1-CHAKRA #1 SMP PREEMPT Sun Nov 18 20:55:05 UTC 2018 x86_64 GNU/Linux

  2. Is this really an issue on PC? We have tons of computing power with fast ram. Our kernel is already about 75MB, but it loads to ram quickly. Using -O3 instead of -O2 will not increase the size of the binary significantly.
    The size of the kernel is an issue on slow embedded (mostly arm) systems, but those are an other area.

(tom) #16


  1. i like the kernel and he works well for me so it doesn’t matter if i am wrong^^
  2. the kernel brings own compile flags and can’t be changed easily, so far as i know

(kepszlok) #17


2: by default, we can choose between optimize for size and -O2, it can be configured in kconfig. -O2 is the default. CC_OPTIMIZE_FOR_SIZE

After some reading, i did changed my mind ower -O3. That my cause problems or even slower code.

On the other hand, LTO is still quite intresting.

(Luca Giambonini) #18

“CK1 patched kernel is clearly the winner here” yes I agree, but for a very small margin.
We should be always careful with the kernel, since is a core part of the system we must be sure to implement something that works for everyone. Adding additional patches just to gain some ms in a test-site can be dangerous, is a no go for me.

True, but the MuQSS is the ck (Con Kolivas) kernel patch set:
I applied the whole set.

I would test this kernel for some weeks and report here any problems. After this period I can move it to testing in order to involve more testers. Thanks

(kepszlok) #19

Just to add some perspective to the differences, i was able to gain 6 second difference in avg kernel build time by setting up my ram from 2133MHz to 3066MHz with the lowest possible timings. And now there is this kernel patch that gives the same 6 second reduction in build time, which is quite good if you ask me.

Btw I do agree with you in the other things. I did not know much about this patch, so there can be hidden problems.
Can we have a third kernel option for this properly patched and set up kernel? I think about keeping it in testing / extra repo, or something like that. Just for us heavy experimenters. The current one hade some modul errors at boot time. :slight_smile:

(tom) #20

@AlmAck @kepszlok
i am using the ck pachset for nearly 5 years without problems so i am am really sure there will be no problems occur with the ck patchset :sunglasses:

this need some investigation so please show: