Kernel Benchmarking Results - Zen, cacULE, TKG, BORE

Model name: Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz

╰─λ uname -a
Linux garuda-iMac 5.17.3-zen1-1-zen #1 ZEN SMP PREEMPT Thu, 14 Apr 2022 01:18:28 +0000 x86_64 GNU/Linux

[[email protected] boot]# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_driver

  • Right now I am booted into stock Garuda zen kernel while obtaining the results above. I will boot into cachyos-bore and check for intel_pstate there as well.



Oh sick, thanks for the detailed reply! Before anything, I must say I really appreciate your work.

Yeah, I was starting to see geekbench's sort of uselessness, lol. I'll check out phoronix, and I'm looking into some stress/load testers as well.

I saw mention of this, but I wasn't exactly clear on the difference. I found steps to check if v3 is supported, but hadn't followed through with that yet.

Yeah, I looked into it, I'll probably start building a db here soon so I can more feasibly build kernels regularly. I didn't do so initially because I was itching to test and for modprobe wanted to follow the recommendation of letting the db fill out for for a few days with everything I need so as to avoid accidentally not loading a module that I needed for something more specific.

I'll have to add the repo, I saw it come up but it felt a better idea to use the ones you'd built for Garuda initially. What do you mean by "our keyring" though? Isn't it an external repo?

I only experienced this with the 5.16.16-1 build of linux-bore from chaotic - other kernels and the updated build of linux-bore didn't have this, so it wasn't a big issue. I'd be willing to look into it more thoroughly if you're curious, though!

Ah man, I was hoping I had a little more time before I ran down this kernel rabbit hole a little deeper :rofl: Suppose I'll wait for this to hit and just run this whole experiment from the top with the update and better benching tools.

Nothing right now, unless you have any specific insight on the actions/mechanisms of power-profiles-daemon and it's interplay with non-standard schedulers and such.

Thanks again! Let me know if there's anything you want me to poke at more specifically, and I'll keep updating this thread. :peace_symbol:


Which is the best kernel to use with blender as a real world test? :smiley:


Blender's performance is probably pretty dependent on RAM+GPU+CPU performance all together. It's also a more specific kind of load, so stuff that's meant for interactivity/general use might not necessarily push the same to getting heavy in blender? That's just conjecture though, :person_shrugging:

You'd probably just have to try a few out. Zen since it's the default shipped with Garuda, LTS if you want a properly stock baseline, then maybe branch out into the other custom's. May just wanna read up on what all is offered in Garuda's kernel manager, there's all kinds of wavy stuff.

Anecdotally, I've continued to have the best experience on the linux-cacULE build provided by ptr1337 above for Garuda.

If you do test this stuff (or wanna look into the mentioned phoronix tools) keep us updated here!


I agree but testing a kernel against real world scenario's is better than bench marking (blender was just a use case) :smiley:


It will be worth looking at linux-lqx too. It's a more "standard" kernel than the more obscure ones here (essentially a more aggressive linux-zen) but with enough differences to make it interesting.


Hey @ptr1337 nice to see you on this topic considering your kernels are a main subject. I do have a question regarding the CPU optimisation script. So I originally built the kernel through makepkg and the package build detected my CPU and compiled it with the necessary flags. But a new build was precompiled on the chaotic aur. So as I compiled it with my optimisations and then updated it through chaotic aur, do I lose my optimisations because the optimisations would be of the person, in this case, @dr460nf1r3 who compiled it? Does this question make sense? I'm basically asking if my optimisations are lost because I updated it from a different person who compiled it with their different optimisations based on the automatic CPU detection. Thanks

Edit: Sorry for any tags. Just wanted to show who is doing what so it's clearer in my question.

Actually cpu's got different the micro architectures. The compilers are using different compile flags which are optimized for the cpu, this results most time in a better performance.
The difference between x86-64 generic to x86-64-v3 should be around 10 %.
Thats the reason why man people also compile their packages theirself (Gentoo best example for it) and use march=native to get their compiled packages optimized to their system.

The CachyOS repo provides most archlinux packages and also the kernel in Generic v3.
Here you can read more about:

And here a How to add the repo:

I did pushed the kernels already with the new changes. I already told @dr460nf1r3 to build them :slight_smile:

Actually I think thats probably a issue from the config since most governor are disabled. I'll fix this with the 5.17.4 push.

Thanks for your feedback! I'll let you know!

Actually for testing a kernels performance with a small script is from @anon34128669 really good.
Just be sure to have all dependencys installed, but i think its also in the aur.

Hey @Grimy1928,

In general chaotic-aur builts them with the generic optimization.
If you use the kernel from another person which compiled it, the person should have the same cpu architecture as you (for example zen3,.. ) or should choose when building the kernel the generic-v3 optimization.

You can change before building between the auto detection or the select:

In general is the Generic v3 Optimization in these times the best to share kernels/packages between systems. Every CPU which was released near intel haswell should support x86-64-v3 optimization.

You can check it with the following command:

/lib/ --help | grep "x86-64-v3 (supported, searched)" 

If you get a output then its supported.



I'd be interested in that answer! :smiley:

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.