I have been using cachyos for quite a while, posted a few times on the forum, and I am very grateful to the mantainers, who are doing a great job. Popularity speaks by itself. So I hope this post is not viewed as a critic, rather as a way to learn from the mantainers/users even as I have a couple of hopefully constructive remarks.
What it the current state of the kernel compilation in cachyos? It would be interesting to know the answer to a few different doubts.
The propeller situation
The official “features” page mentions that the kernel is compiled with autoFDO+propeller, but the .config in the standard kernel shows this
CONFIG_CC_VERSION_TEXT="clang version 21.1.6"
CONFIG_CC_IS_CLANG=y
CONFIG_CLANG_VERSION=210106
CONFIG_LTO_CLANG=y
CONFIG_ARCH_SUPPORTS_LTO_CLANG=y
CONFIG_ARCH_SUPPORTS_LTO_CLANG_THIN=y
CONFIG_HAS_LTO_CLANG=y
# CONFIG_LTO_CLANG_FULL is not set
CONFIG_LTO_CLANG_THIN=y
# CONFIG_LTO_CLANG_THIN_DIST is not set
CONFIG_ARCH_SUPPORTS_AUTOFDO_CLANG=y
CONFIG_AUTOFDO_CLANG=y
CONFIG_ARCH_SUPPORTS_PROPELLER_CLANG=y
# CONFIG_PROPELLER_CLANG is not set
in principle it is possible to disable the propeller symbol before the final compilation, but it would be rather unusual to do it for propeller and not for autoFDO. So it seems propeller is not being applied.
Currently compiling with autoFDO+propeller with LTO is not straightforward; moreover it was unclear that propeller was providing much benefit the last time I tested. This is going to change in LLVM 23, where propeller should be finally merged upstream, and the autoFDO+propeller workflow and consistency should be finally simplified and optimized.
The BOLT situation
In this blog post they say
### BOLT
BOLT has also recently added support for the kernel.
There is currently a kernel patch pending for it, but this one will be also posted on lkml in the near future.
BOLT can be even applied after AutoFDO and Propeller.
This is not completely accurate. BOLT can be applied post-linking, but in principle it is complementary (in a negative sense) to propeller. While they optimize at different stages, BOLT optimization should neutralize/be detrimental to propeller optimization. I had tried to test this last year, but basically autoFDO+propeller+LTO+BOLT+some_patches_of_mine never gave me a working kernel, but I would still be very very surprised if BOLT after propeller would give any benefit. I think the basic idea is that, for the kernel, autoFDO+propeller is a better option, especially once propeller is merged upstream in LLVM.
The kernels repo
In general I find the kernel repo a bit messy but also quite interesting. Some kernels (standard, hardened, lts, rc) are great additions (for security, fallback, testing before updating) even for the typical user. Some other are likely more niche but still a great resource. I guess it is hard to track the popularity of the various kernel flavors, but for instance it is not clear to me the difference between eevdf and the standard kernel (which I think dropped BORE). So I wonder if there is any sort of upcoming testing version, where LLVM23 compilation is tested once propeller lands upstream.
There are some questions of “taste”. For instance I wonder if it would not be easier to manage a unique PKGBUILD with a separate configuration file for the different builds. Also, the README seems outdated btw.
A side remark
There are also some dubious symbols choices, for instance I see in the standard kernel
CONFIG_CPUMASK_OFFSTACK=y
CONFIG_NR_CPUS_RANGE_BEGIN=8192
CONFIG_NR_CPUS_RANGE_END=8192
CONFIG_NR_CPUS_DEFAULT=8192
CONFIG_NR_CPUS=8192
maybe this makes sense for the server version (hardly so), but it is a waste of memory on any other build. I do not see anyone with a machine needing CPUMASK_OFFSTACK using the standard kernel, even less if someone needs 8192 cpus. This is around 70Mb of wasted reserved memory. Maybe this is inherited from the arch kernel, still to me it makes sense to change these defaults on any optimized build.
Thanks to anyone reading so far or providing some insight. I think many landed on cachyos as gamers. But on my side, I see it as a great implementation of what “Clear Linux” (RIP) should have been, and a user-friendly transition toward a custom optimized half-stateless linux. So these doubts stem from this point of view.