From ArchWiki
Jump to: navigation, search

According to Wikipedia:

The kernel is a computer program that constitutes the central core of a computer's operating system. It has complete control over everything that occurs in the system. As such, it is the first program loaded on startup, and then manages the remainder of the startup, as well as input/output requests from software, translating them into data processing instructions for the central processing unit. It is also responsible for managing memory, and for managing and communicating with computing peripherals, like printers, speakers, etc. The kernel is a fundamental part of a modern computer's operating system.

There are various alternative kernels available for Arch Linux in addition to the stable Linux kernel. This article lists some of the options available in the repositories with a brief description of each. There is also a description of patches that can be applied to the system's kernel. The article ends with an overview of custom kernel compilation with links to various methods.

Officially supported

  • Stable — Vanilla Linux kernel and modules, with a few patches applied. || linux
  • Hardened — A security-focused Linux kernel applying a set of hardening patches to mitigate kernel and userspace exploits. It also enables more upstream kernel hardening features than linux along with user namespaces (with unprivileged usage disabled by default via a patch), audit and SELinux. || linux-hardened
  • Longterm — Long-term support (LTS) Linux kernel and modules. || linux-lts
  • ZEN Kernel — Result of a collaborative effort of kernel hackers to provide the best Linux kernel possible for everyday systems. Some more details can be found on (which provides kernel binaries based on ZEN for Debian). || linux-zen


Arch Linux provides two methods of kernel compilation.

Using Arch Build System

Takes advantage of the high quality of existing linux PKGBUILD and the benefits of package management.

See Kernels/Arch Build System.


This involves manually downloading a source tarball, and compiling in your home directory as a normal user.

See Kernels/Traditional compilation.

Patches and patchsets

There are lots of reasons to patch your kernel, the major ones are for performance or support for non-mainline features such as reiser4 file system support. Other reasons might include fun and to see how it is done and what the improvements are.

However, it is important to note that the best way to increase the speed of your system is to first tailor your kernel to your system, especially the architecture and processor type. For this reason using pre-packaged versions of custom kernels with generic architecture settings is not recommended or really worth it. A further benefit is that you can reduce the size of your kernel (and therefore build time) by not including support for things you do not have or use. For example, you might start with the stock kernel config when a new kernel version is released and remove support for things like bluetooth, video4linux, 1000Mbit ethernet, etc.; functionality you know you will not require for your specific machine. Although this page is not about customizing your kernel config, it is recommended as a first step--before moving on to using a patchset once you have grasped the fundamentals involved.

The config files for the Arch kernel packages can be used as a starting point. They are in the Arch package source files, for example [1] linked from linux. The config file of your currently running kernel may also be available in your file system at /proc/config.gz if the CONFIG_IKCONFIG_PROC kernel option is enabled.

If you have not actually patched or customized a kernel before it is not that hard and there are many PKGBUILDs on the forum for individual patchsets. However, you are advised to start from scratch with a bit of research on the benefits of each patchset, rather than just arbitrarily picking one. This way you will learn much more about what you are doing rather than just choosing a kernel at startup and then be left wondering what it actually does.

Major patchsets

Warning: Patchsets are developed by a variety of people. Some of these people are actually involved in the production of the linux kernel and others are hobbyists, which may reflect its level of reliability and stability.
  • Linux-ck — Contains patches by Con Kolivas designed to improve system responsiveness with specific emphasis on the desktop, but suitable to any workload. || linux-ckAUR
  • pf-kernel — Provides you with a handful of awesome features not merged into mainline. It is based on neither existing Linux fork nor patchset, although some unofficial ports may be used if required patches have not been released officially. The most prominent patches of linux-pf are PDS CPU scheduler and UKSM. || Packages:
  • Realtime kernel — Maintained by a small group of core developers, led by Ingo Molnar. This patch allows nearly all of the kernel to be preempted, with the exception of a few very small regions of code ("raw_spinlock critical regions"). This is done by replacing most kernel spinlocks with mutexes that support priority inheritance, as well as moving all interrupt and software interrupts to kernel threads. || linux-rtAUR, linux-rt-ltsAUR

Other patchsets

Some of the listed packages may also be available as binary packages via Unofficial user repositories.

  • Aufs — The aufs-compatible linux kernel and modules, useful when using docker. || linux-aufs_friendlyAUR
  • BLD — Best described as a O(1) CPU picking technique. Which is done by reordering CPU runqueues based on runqueue loads. In other words, it keeps the scheduler aware of the load changes, which helps scheduler to keep runqueues in an order. This technique does not depend on scheduler ticks. The two most simple things in this technique are: load tracking and runqueue ordering; these are relatively simpler operations. Load tracking will be done whenever a load change happens on the system and based on this load change runqueue will be ordered. So, if we have an ordered runqueue from lowest to highest, then picking the less (or even busiest) runqueue is easy. Scheduler can pick the lowest runqueue without calculation and comparison at the time of placing a task in a runqueue. And while trying to distribute load at sched_exec and sched_fork our best choice is to pick the lowest busiest runqueue of the system. And in this way, system remains balanced without doing any load balancing. At the time of try_to_wake_up picking the idlest runqueue is topmost priority but it has been done as per domain basis to utilize CPU cache properly and it's an area where more concentration is requires. || linux-bldAUR
  • Git — Linux kernel and modules built using sources from Linus Torvalds' Git repository || linux-gitAUR
  • Libre — The Linux Kernels without "binary blobs". || linux-libreAUR
  • Liquorix — Kernel replacement built using Debian-targeted configuration and the ZEN kernel sources. Designed for desktop, multimedia, and gaming workloads, it is often used as a Debian Linux performance replacement kernel. Damentz, the maintainer of the Liquorix patchset, is a developer for the ZEN patchset as well. || linux-lqxAUR
  • Longterm 4.4 — Long-term support (LTS) Linux 4.4 kernel and modules. || linux-lts44AUR
  • Mainline — The Mainline Linux Kernel and modules. || linux-mainlineAUR
  • MultiPath TCP — The Linux Kernel and modules with Multipath TCP support. || linux-mptcpAUR
  • Reiser4 — Successor filesystem for ReiserFS, developed from scratch by Namesys and Hans Reiser. || reiser4progsAUR
  • VFIO — The Linux kernel and a few patches written by Alex Williamson (acs override and i915) to enable the ability to do PCI Passthrough with KVM on some machines. || linux-vfioAUR, linux-vfio-ltsAUR

See also