Chapter 12. Kernel
This chapter lists the most notable changes to kernel between RHEL 8 and RHEL 9.
12.1. Notable changes to kdump memory allocation
kexec-tools package now supports the default
crashkernel memory reservation values for RHEL 9
kexec-tools package now maintains the default
crashkernel memory reservation values. The
kdump service uses the default value to reserve the
crashkernel memory for each kernel. This implementation also improves memory allocation for
kdump when a system has less than 4GB of available memory.
If the memory reserved by the default
crashkernel value is not sufficient on your system, you can increase the
crashkernel parameter using the default value as a reference.
To query the default
$ kdumpctl get-default-crashkernel
Note that the
crashkernel=auto option in the boot command line is no longer supported on RHEL 9 and later releases.
For more information, see the
12.2. Notable changes to the RHEL for Real Time kernel
The TPM 1.2 secure cryptoprocessor is no longer supported on RHEL 9
The Trusted Platform Module (TPM) secure cryptoprocessor version 1.2 has been removed and is no longer supported on RHEL 9 and later versions. TPM 2.0 replaces TPM 1.2 and provides many improvements over TPM 1.2. TPM 2.0 is not backward compatible.
Note that for applications that require support for TPM 1.2, Red Hat recommends that you use RHEL 8.
Dynamic preemptive scheduling enabled on ARM, AMD, and Intel 64-bit architectures
Using Dynamic Scheduling, you can change the preemption mode of the kernel at boot or runtime instead of compile time. With dynamic preemptive handling, you can override the default preemption model to improve scheduling latency.
/sys/kernel/debug/sched/preempt file contains the current setting that supports runtime modification. Using the
DYNAMIC_PREEMPT option, set the
preempt= variable at boot to either
voluntary preemption is the default.
A new command line interface has been added to the
tuna tool now provides a command line interface with more standardized menu of commands and options that is easier to use and maintain. The new command line interface is based on the
argparse parsing module. With this enhancement, you can perform the following tasks:
- Change the attributes of the application and kernel threads.
- Operate on interrupt requests (IRQs) by name or number.
- Operate on tasks or threads by using the process identifier.
- Specify CPUs and sets of CPUs with the CPU or the socket number.
By using the
tuna -h command, you can print the command line arguments and their corresponding options. For each command, there are optional arguments, which you can view with the
tuna [command] -h command.
The runtime verification mechanism available for real-time kernel
Runtime verification is a lightweight and rigorous method to check the behavioral equivalence between system events and its formal specifications. Runtime verification has monitors integrated in the kernel that attach to
tracepoints. If a state deviates from defined specifications, the runtime verification program activates reactors to inform or enable a reaction such as capturing the event in the log file or a system shutdown to avoid failure propagation in an extreme case.
For more information see, Optimizing RHEL 9 for Real Time for low latency operation.
12.3. Notable changes to kernel
The 64k page size kernel
In addition to the RHEL 9 for ARM kernel which supports 4k pages, Red Hat now offers an optional kernel package that supports 64k pages:
The 64k page size kernel is a useful option for large datasets on ARM platforms. It enables better performance for some types of memory- and CPU-intensive operations.
You must choose page size on 64-bit ARM architecture systems at the time of installation. You can install
kernel-64k only by Kickstart by adding the
kernel-64k package to the package list in the
For more information about installing
kernel-64k, see Performing an advanced RHEL 9 installation.
cgroup-v2 enabled by default in RHEL 9
The control groups version 2 (
cgroup-v2) feature implements a single hierarchy model that simplifies the management of control groups. Also, it ensures that a process can only be a member of a single control group at a time. Deep integration with
systemd improves the end-user experience when configuring resource control on a RHEL system.
Development of new features is mostly done for
cgroup-v2, which has some features that are missing in
cgroup-v1 contains some legacy features that are missing in
cgroup-v2. Also, the control interfaces are different. Therefore, third party software with direct dependency on
cgroup-v1 may not run properly in the
cgroup-v1, you need to add the following parameters to the kernel command-line:
cgroup-v2 are fully enabled in the kernel. There is no default control group version from the kernel point of view, and is decided by
systemd to mount at startup.
Kernel changes potentially affecting third party kernel modules
Linux distributions with a kernel version prior to 5.9 supported exporting GPL functions as non-GPL functions. As a result, users could link proprietary functions to GPL kernel functions through the
shim mechanism. With this release, the RHEL kernel incorporates upstream changes that enhance the ability of RHEL to enforce GPL by rebuffing
Partners and independent software vendors (ISVs) should test their kernel modules with an early version of RHEL 9 to ensure their compliance with GPL.
Core scheduling is supported in RHEL 9
With the core scheduling functionality users can prevent tasks that should not trust each other from sharing the same CPU core. Likewise, users can define groups of tasks that can share a CPU core.
These groups can be specified:
- To improve security by mitigating some cross-Symmetric Multithreading (SMT) attacks
- To isolate tasks that need a whole core. For example for tasks in real-time environments, or for tasks that rely on specific processor features such as Single Instruction, Multiple Data (SIMD) processing
For more information, see Core Scheduling.
kernelopts environment variable has been removed in RHEL 9
In RHEL 8, the kernel command-line parameters for systems using the GRUB2 bootloader were defined in the
kernelopts environment variable. This variable was stored in the
/boot/grub2/grubenv file for each kernel boot entry. However, storing the kernel command-line parameters using
kernelopts was not robust. Therefore, Red Hat removed
kernelopts and the kernel command-line parameters are now stored in the Boot Loader Specification (BLS) snippet, instead of in the
Red Hat protects kernel symbols only for minor releases
Red Hat guarantees that a kernel module will continue to load in all future updates within an Extended Update Support (EUS) release, only if you compile the kernel module using protected kernel symbols. There is no kernel Application Binary Interface (ABI) guarantee between minor releases of RHEL 9.
12.4. Notable changes to boot loader
Boot loader menu hidden by default
Starting with RHEL 9.1, the GRUB boot loader is now configured to hide the boot menu by default if RHEL is the only installed operating system and if the previous boot succeeded. This results in a smoother boot experience on such systems.
To access the boot menu, use one of the following options:
- Repeatedly press Esc after booting the system.
- Repeatedly press F8 after booting the system.
- Hold Shift during boot.
To disable this function and configure the boot loader menu to display by default, use the following command:
# grub2-editenv - unset menu_auto_hide
Boot loader configuration files are unified across CPU architectures
Configuration files for the GRUB boot loader are now stored in the
/boot/grub2/ directory on all supported CPU architectures. The
/boot/efi/EFI/redhat/grub.cfg file, which GRUB previously used as the main configuration file on UEFI systems, now simply loads the
This change simplifies the layout of the GRUB configuration file, improves user experience, and provides the following notable benefits:
- You can boot the same installation with either EFI or legacy BIOS.
- You can use the same documentation and commands for all architectures.
- GRUB configuration tools are more robust, because they no longer rely on symbolic links and they do not have to handle platform-specific cases.
- The usage of the GRUB configuration files is aligned with images generated by CoreOS Assembler (COSA) and OSBuild.
- The usage of the GRUB configuration files is aligned with other Linux distributions.
RHEL no longer boots on 32-bit UEFI
Support for the 32-bit UEFI firmware was removed from the GRUB and
shim boot loaders. As a consequence, RHEL 9 requires a 64-bit UEFI, and can no longer boot on 64-bit systems that use a 32-bit UEFI.
The following packages have been removed as part of this change: