By introducing feature patches which menu options that are disabled by default to genpatches (the Gentoo kernel patches), we deduplicate the work the *-sources maintainers have to do do as well as make it easier for a large groups of users so they do not manually need to apply the patch anymore and simply just have to enable it. In genpatches, since 3.9.7, BFQ was added to try this out. We have ensured it to be disabled by default, that it did not affect the build for anyone that does not enable it and as a result users have been enabling and using it on their own. Those that didn't want to use it were not affected.
USE flags for sys-kernel/gentoo-sources Full sources including the Gentoo patchset for the 5.10 kernel tree
||!!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used for creating build images and the first half of bootstrapping [make stage1]|
||Apply experimental patches; for more information, see "https://wiki.gentoo.org/wiki/Project:Kernel/Experimental".|
||Force kernel ebuilds to automatically update the /usr/src/linux symlink|
To make the the experimental patches apply, you need to enable
USE="experimental". After setting that and emerging a kernel package that supports this USE flag again, you can use make oldconfig after making sure your .config is present (like a typical upgrade) to configure them. For more information on how a kernel upgrade happens, read this article. Please note that
USE="experimental" only applies the patches but does not enable their options; by default, none of the code that gets applied will be build into the kernel. So, you need to enable the options the experimental patches provide in the oldconfig or the menuconfig. Our goal here is not at all to build everything into the kernel; quite the opposite, we want you to explicitly decide that just like with the rest of the kernel.
Currently this is only supported in sys-kernel/gentoo-sources but we hope to see other source packages to adapt this functionality in the near future.
We cannot guarantee that the patches are available when they break against upstream code; but we will do our best to make them available as soon as possible, depending on the breakage we manually adapt the patch against the upstream changes or await a fix from upstream. You can use the Status section below to track the status of the patches; so, if the status has updated to indicate it is available and works again, you can simply re-emerge the sources. Due to the way merging the kernel works, your .config will not be overwritten by doing that. If you have a fix we do not have yet and want to help out other experimental patches users; you are welcome to file and attach it at our bug tracker, we will the check and apply it as soon as possible.
Dealing with patch conflicts (if you use user patches)
Those who want to more explicitly control which experimental patches get applied, for example when one of the experimental patches conflict with one of your user patches; you can create something like /etc/portage/env/sys-kernel/gentoo-sources where you can use variables like K_EXP_GENPATCHES_PULL="yes" K_EXP_GENPATCHES_LIST="" or UNIPATCH_EXCLUDE="" to respectively opt-in and opt-out control which experimental patches get applied. This allows you to control which ones get applied as you see fit. We suggest you to use the second technique which excludes certain paches. Here are two examples:
Please note that above file ignores the USE flag state as it is was meant for ebuild maintainers; since users will only come across patch collisions problems, they will want to opt-out certain patches:
You see that I use BFQ here as a value as example; this will match any patches named *BFQ*, it is matching using wildcards so that way the full patch name (which might change) doesn't have to be specified.
More information on user patches can be found in the /etc/portage/patches article.
This document aims to give an overview of the current status of the experimental patches in the available kernel releases.
|3.9.11||BFQ disk scheduler v6r2||No|
|3.10.7 - 3.10.10||BFQ disk scheduler v6r2||No|
|3.10.11 - 3.10.*||BFQ disk scheduler v6r2||Yes|
|3.11.* - 3.12.*||BFQ disk scheduler v6r2||Yes|
|3.13.0 - 3.13.1||BFQ disk scheduler v6r2||Yes|
|3.13.2 - 4.11.12||BFQ disk scheduler v6r2; additional CPU optimizations for GCC||Yes|
|4.12.0 - ...||additional CPU optimizations for GCC||Yes|
From 3.10.11 and 3.11 onward, experimental patches will now be available using an experimental USE flag as explained above; such that they do not longer apply by default.
Overview of experimental patches
Currently we only provide BFQ and a GCC optimizations patch to further revise our tools for providing experimental patches, we plan to add more of the most common patches later.
BFQ is a proportional-share disk scheduling algorithm that also supports hierarchical scheduling with a cgroups interface. Here are the main nice features of BFQ:
- Low latency for interactive applications.
- Low latency for soft real-time applications.
- High throughput.
- Strong fairness guarantees.
The above is quoted from BFQ and related stuff on disk scheduling where you can find more information.
Additional CPU optimizations for GCC
This kernel patch adds additional CPU options to the Linux kernel accessible under: Processor type and features ---> Processor family
The above is quoted from graysky2/kernel_gcc_patch README.md where you can find more information.
It is worth noting that these optimizations meet ANOVA assumptions; and thus, small but real speed increases can be experienced.