[RFC] Consider removal of some PKGBUILD options

[ventureoo]

I think the fact that we provide a lot of options to customize the kernel build right in PKGBUILD is great, but some of them (in my opinion) are pretty useless and 98% of the time are not used in any way and just distract user. For example:

• _NUMAdisable - as stated in the comment, it makes no sense from a performance standpoint to disable NUMA these days. Many workloads require NUMA, in the past disabling NUMA has also caused issues with CUDA. Some custom kernels like linux-lqx have already dropped this option: https://aur.archlinux.org/cgit/aur.git/commit/?h=linux-lqx&id=bf16ff7f8d2d70bc95e962e0865363411b7a61c8. So I don't see the point of keeping it for our PKGBUILDs. If someone actually wants to do this, they can always do it via nconfig.

• _hugepage - I don't remember us ever changing default THP mode other than always. First, it doesn't make sense because always has good performance for desktop workloads, second it can always be changed at runtime. So changing it at compile time seems pointless to me.

• _per_gov- We have long since abandoned the use of a performance governor by default, and just as with _hugepage this can be always changed in runtime and in CachyOS we provide all tools to do so as a PPD/game-performance script.

• _cc_harder - We and pretty much all other kernels except stock have been using O3 by default for years and haven't seen any major regressions. There are many tests here confirming performance gains in a number of cases. So I have no idea why someone might want to turn O3 off, but as before, if someone wants to do it - they can do it via nconfig.

• _makexconfig / _makemenuconfig - Too many configurators for the kernel. I haven't seen anyone using _makexconfig instead of _makegconfig yet, because obviously I have no idea what pros of that are, and besides it's not supported on purely Wayland environments. Also _makemenuconfig looks a bit pointless to me in the presence of nconfig, which looks more tidy and understandable.

Removing the options above will make PKGBUILD a little cleaner and clearer for the user. There are a few other options that I find questionable, but in general I would like to discuss only those mentioned above.

[ptr1337]

_hugepage - I don't remember us ever changing default THP mode other than always. First, it doesn't make sense because always has good performance for desktop workloads, second it can always be changed at runtime. So changing it at compile time seems pointless to me.

This is thought for users and also the RT kernel, whcih prefer latency over throughput

_per_gov- We have long since abandoned the use of a performance governor by default, and just as with _hugepage this can be always changed in runtime and in CachyOS we provide all tools to do so as a PPD/game-performance script.

We have many users, which are compiling their kernel on their own. Many prefer to use the performance gov as default

_makexconfig / _makemenuconfig - Too many configurators for the kernel. I haven't seen anyone using _makexconfig instead of _makegconfig yet, because obviously I have no idea what pros of that are, and besides it's not supported on purely Wayland environments. Also _makemenuconfig looks a bit pointless to me in the presence of nconfig, which looks more tidy and understandable.

makenconfig should be enough, yes

[ventureoo]

This is thought for users and also the RT kernel, whcih prefer latency over throughput

If it matters to anyone, like I said it can be switched in runtime, and that seems much easier to me than rebuilding the kernel. As for RT, it's not possible in upstream right now, as CONFIG_TRANSPARENT_HUGEPAGE depends on the kernel not being RT.

We have many users, which are compiling their kernel on their own. Many prefer to use the performance gov as default

Since 5.8 there is a kernel parameter cpufreq.default_governor that allows this to be set without rebuilding the kernel, so if someone prefers it, I think they prefer it on all kernels, hence they only need to set the parameter in the bootloader config instead of rebuilding kernels. For casual users there is even a GUI like the built-in widgets in GNOME/KDE (PPD integration), or cpupower-gui if P-State driver is not supported.

[1Naim]

I don't really mind removing these because as you've said, these options are hardly ever touched and can be enabled/disabled on runtime. It would be nice to get some comments from actual users to know their opinions on things, and probably the percentage of users that actually use these features.

As some additional info, if we're being more radical we can remove these other two: a. $_tcp_bbr3 = This can also be changed on runtime too and we could also set this in cachyos-settings. I personally believe this exists because it was the default not too long ago. I'm not sure when we're going to enable it by default again so that may just be the last justification to keep this. b. $_preempt = dynamic preempt exists, and while there are compile-time differences between a preemptible kernel vs non-preemptible, I think it hardly matters. I also don't believe there are sane users that would use preempt=none on a preemptible kernel. The only reason we would keep this would be when we move rt from cpusched -> preempt. IMO we should do this when we don't have any additional rt patches, but the ETA for that is unclear.

[ventureoo]

_makexconfig / _makemenuconfig - Too many configurators for the kernel. I haven't seen anyone using _makexconfig instead of _makegconfig yet, because obviously I have no idea what pros of that are, and besides it's not supported on purely Wayland environments. Also _makemenuconfig looks a bit pointless to me in the presence of nconfig, which looks more tidy and understandable.

There was some misunderstanding of configurators on my part here. _makexconfig is not actually a configurator on pure X as one might think from the name, but on Qt 5/Qt 6. At the same time _makegconfig seems to still use GTK 2, so it seems this _makegconfig is better to remove and leave _makexconfig.

[1Naim]

• _cc_harder - We and pretty much all other kernels except stock have been using O3 by default for years and haven't seen any major regressions. There are many tests here confirming performance gains in a number of cases. So I have no idea why someone might want to turn O3 off, but as before, if someone wants to do it - they can do it via nconfig.

So just to make some progress on this, the switch in PKGBUILDs doesn't actually work, i.e. if it's set to no it will still use O3 because the config already sets O3 by default. I've fixed this in the hardened config but I didn't fix for the other kernels because dropping this makes sense to me IMO.

• _per_gov- We have long since abandoned the use of a performance governor by default, and just as with _hugepage this can be always changed in runtime and in CachyOS we provide all tools to do so as a PPD/game-performance script.

Although I haven't really verified if this is true or not, but since we use power-profiles-daemon. All supported systems (amd-pstate and intel-pstate) will default to the governor used by the current default profile. So I believe that this config won't work either with ppd.

[1Naim]

I think another contender for droppage is _tickrate. Reasonings are as follows:

1. NO_HZ_FULL without any extra configuration behaves exactly like NO_HZ_IDLE[1]. Users need to explicitly mark which CPUs to be adaptive-tick (full tickless) with the nohz_full boot option.
2. Default NO_HZ_FULL / NO_HZ_IDLE is what 99% of users are want to use. HZ_PERIODIC and actual adaptive-tick aren't really useable for the desktop, and is only used for realtime systems.
3. NO_HZ_IDLE can fallback to HZ_PERIODIC with nohz=off (haven't checked if this is the case with NO_HZ_FULL too)

[1] https://github.com/torvalds/linux/blob/ffd294d346d185b70e28b1a28abe367bbfe53c04/kernel/time/Kconfig#L142-L143

[ptr1337]

I think another contender for droppage is _tickrate. Reasonings are as follows:

1. `NO_HZ_FULL` without any extra configuration behaves exactly like `NO_HZ_IDLE`[1]. Users need to explicitly mark which CPUs to be adaptive-tick (full tickless) with the `nohz_full` boot option.

2. Default `NO_HZ_FULL` / `NO_HZ_IDLE` is what 99% of users are want to use. `HZ_PERIODIC` and actual adaptive-tick aren't really useable for the desktop, and is only used for realtime systems.

3. `NO_HZ_IDLE` can fallback to `HZ_PERIODIC` with `nohz=off` (haven't checked if this is the case with `NO_HZ_FULL` too)

[1] https://github.com/torvalds/linux/blob/ffd294d346d185b70e28b1a28abe367bbfe53c04/kernel/time/Kconfig#L142-L143

There are a bunch of users actively using this options to compile their kernel. As it is with preemption, you dont know how stable or well working the kernel commandline is working neither.

[ventureoo]

I think another contender for droppage is _tickrate. Reasonings are as follows:

1. `NO_HZ_FULL` without any extra configuration behaves exactly like `NO_HZ_IDLE`[1]. Users need to explicitly mark which CPUs to be adaptive-tick (full tickless) with the `nohz_full` boot option.

2. Default `NO_HZ_FULL` / `NO_HZ_IDLE` is what 99% of users are want to use. `HZ_PERIODIC` and actual adaptive-tick aren't really useable for the desktop, and is only used for realtime systems.

3. `NO_HZ_IDLE` can fallback to `HZ_PERIODIC` with `nohz=off` (haven't checked if this is the case with `NO_HZ_FULL` too)

[1] https://github.com/torvalds/linux/blob/ffd294d346d185b70e28b1a28abe367bbfe53c04/kernel/time/Kconfig#L142-L143

There are a bunch of users actively using this options to compile their kernel. As it is with preemption, you dont know how stable or well working the kernel commandline is working neither.

My point is that if a user really wants to change some kernel parameters, they should look for the shortest and easiest way to do it. Recompiling the kernel to change the default is not an easy way for most users. In the Plasma widget, moving the slider to “Performance” is much more convenient and easier, and even if your CPU doesn't support P-State so PPD doesn't work, there have always been a bunch of utilities and options to easily change the governor. Similarly with the other settings I mentioned. There are many easy ways to change kernel parameters through the bootloader configuration. I understand the point of view that you can rebuild kernel all-in-one, but I don't see much sense in that. At the same time, those kernel-manager users who don't understand all the nuances may mistakenly rebuild their kernel with parameters that make performance, or power efficiency in the case of laptops, worse.

[ninetailedtori]

I do actually use the hugepage madvise option, but the others, if they're included by default, we can drop them now. Another thing that might be possible to drop might be ASKING for nvidia and nvidia-open compilation tags, as well as all the tags that ask if the user wants to add suffixes, which could all be automated from the options instead. nvidia/open options would need to be automated for multiple cases though:

1. those that use the cachyos-nvidia/open packages would have it autocompile with that straight through and not need to compile the mainline dkms packages specifically into the kernel.
2. those that use the non-kernelspecific nvidia/open packages, would have it automatically activated to compile support into the kernel.
3. those that use neither, would have no support added to the kernel.

CPU/GPU support, etc. all can be optimised in accordance with gcc test-runs, but my only request with adding flags is, many of the users optimising PKGBUILDs, will have already optimised their linker, their c flags, cxx flags, make flags, ninja flags, so it could be worth adding some level of choice on whether to use the cachyos recommended flags or allow some users to overwrite them as well.