Project:Kernel/Experimental

From Gentoo Wiki
Jump to: navigation, search

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 flag (what is that?) Default Recommended Description
experimental No Apply experimental patches; for more information, see "https://wiki.gentoo.org/wiki/Project:Kernel/Experimental".

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

Important
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)

If you 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:

FILE /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:

FILE /etc/portage/env/sys-kernel/gentoo-sourcesApply all experimental patches except for the BFQ patches
UNIPATCH_EXCLUDE="BFQ"

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.

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 - ... BFQ disk scheduler v6r2, 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 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.

Resources

Gentoo Development Mailing List