[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.