Project:Kernel/Experimental
Information
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.
Usage
USE flags for sys-kernel/gentoo-sources Full sources including the Gentoo patchset for the 6.8 kernel tree
build
|
!!internal use only!! DO NOT SET THIS FLAG YOURSELF!, used for creating build images and the first half of bootstrapping [make stage1] |
experimental
|
Apply experimental patches; for more information, see "https://wiki.gentoo.org/wiki/Project:Kernel/Experimental". |
symlink
|
Force kernel ebuilds to automatically update the /usr/src/linux symlink |
To make the the experimental patches apply, enable the USE="experimental" USE flag and (re)emerge the kernel package. Run make oldconfig after making sure the .config file 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. The experimental options will need to be enabled as necessary using a kernel configuration interface (oldconfig, menuconfig, etc.). The goal here is not at all to build everything into the kernel; quite the opposite, system administrators should explicitly decide what is built just like with the rest of the kernel.
Currently this is only supported in the sys-kernel/gentoo-sources package, but the project members hope to see other source packages to adapt this functionality in the 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. The Status section below can be be used to track the status of the patches; so, if the status has updated to indicate it is available and works again; simply re-emerge the sources. Due to the way merging the kernel works, the .config will not be overwritten by doing that. When a fix we do not have yet is available and you 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 (pulled in via 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 a 'custom patch' provided via user patches. Something like the following can be created /etc/portage/env/sys-kernel/gentoo-sources where variables like K_EXP_GENPATCHES_PULL="yes" K_EXP_GENPATCHES_LIST="" or UNIPATCH_EXCLUDE="" can be leveraged to respectively opt-in and opt-out control which experimental patches get applied. This allows the system administrator to control which patches get applied as necessary. We suggest the second technique which excludes certain patches. Here are two examples:
/etc/portage/env/sys-kernel/gentoo-sourcesOnly apply certain experimental BFQ patches (with USE=-genpatches)K_EXP_GENPATCHES_PULL="yes"
K_EXP_GENPATCHES_LIST="BFQ"
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:
/etc/portage/env/sys-kernel/gentoo-sourcesApply all experimental patches except for the BFQ patchesUNIPATCH_EXCLUDE="BFQ"
Notice that BFQ is used 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.
Status
This document aims to give an overview of the current status of the experimental patches in the available kernel releases.
| Version(s) | Patches | Separate tarball |
|---|---|---|
| 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
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 more information can be found.
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 more information can be found.
It is worth noting that these optimizations meet ANOVA assumptions; and thus, small but real speed increases can be experienced.