Linux 6.19-rc1: Key features of the new kernel and first performance tests

  • Linux 6.19-rc1 released with integration window closure and deep changes to several subsystems.
  • Initial tests compare Linux 6.19 against 6.18 with occasional improvements and early performance regressions.
  • New RTC drivers for Apple Silicon and NVIDIA Tegra platforms, plus support for Andes.
  • Advances in Rust, LoongArch32 and optimizations for HPC workloads on latest generation AMD EPYC processors.

nLinux 6.19-rc1

The publication de Linux 6.19-rc1 This marks the end of the integration window for this kernel version and offers a glimpse into the direction things will take in the coming months. Although it's still an early stage of the cycle, significant changes are already visible in key subsystems, new supported architectures, and a noticeable impact on performance according to initial benchmark tests. Linux 6.18 stable.

The candidate version also arrives in a somewhat peculiar context: Linus Torvalds has brought the announcement forward by a few hours. Because he's in Japan, where he's been attending the Linux Plumbers Conference and the Linux Kernel Maintainer Summit. This slight change of schedule has caught more than one maintainer off guard, as they were trying to push through the latest integration request against the deadline.

An atypical integration window but with a "normal" pattern

Torvalds explained that this integration window has been slightly different from usual For two reasons: several maintainers have been working on the Summit maintainer, and at the same time, several change sets have been included dedicated to expanding the use of the compiler's automatic cleanup infrastructure. This work has been observed in different subsystems, although the VFS layer stands out due to the magnitude of their conversions.

In the section Rust within the kernelThe project is beginning to move beyond the purely preparatory phase. Until now, the foundations and infrastructure have predominated, but with Linux 6.19-rc1, we are starting to see the beginnings. controllers and subsystems actually written in Rust taking shape, something that, if it consolidates, could gain importance in future versions.

Linux 6.18
Related article:
Linux 6.18 arrives loaded: new drivers, more performance, and major advances in Apple Silicon and AMD/Intel

In rough figures, around the Half of the patches in this RC1 correspond to driversThe most notable changes are to GPUs, networking, sound, and media, although there are changes scattered throughout virtually every part of the kernel. The rest are divided between architecture updates, tools, documentation, Rust support, and tweaks to internal components such as memory (mm), the scheduler, the network stack, and other core components.

Linux 6.19-rc1 vs. 6.18: First performance tests

As the integration window closed, the First comparisons between Linux 6.18 stable and the Git state of 6.19 prior to rc1. The tests were performed with the same kernel configuration file and only accepting the new default values ​​proposed by the 6.19 branch, without any other changes to the operating system.

In the first scenario, a AMD EPYC 9655P single-processor server with 96 cores and 192 threads, mounted on a Supermicro H13SSL-N board and running Ubuntu 25.10. The goal was to measure the direct impact of the kernel version jump on a modern server environment with hardware that is becoming common in European data centers.

Initial results show a mixed picture: Some tests point to slight performance improvementsWhile some kernels show significant regressions for such an early stage of development, this is not uncommon in a pre-rc1 release, but it serves as a warning to administrators and advanced users considering deploying this kernel in sensitive environments.

Early regressions in the scheduler and network stack

Stress tests with Stress-NG has uncovered significant setbacks in certain scenarios. Specifically, the following have been observed large regressions in mixed scheduler performance and socket operations compared to stable Linux 6.18. These behaviors, measured with microbenchmarks, are among the most striking within the set of tests performed.

Similarly, when running the network tool Microsoft Ethr on localhost Linux 6.19 has also been observed to be at a clear disadvantage compared to 6.18, with lower network performance in this early stage of the code. This is an early indication that certain adjustments to the scheduler and network stack may need revision before the stable release.

It's not all bad news: within the Stress-NG tests themselves, some issues have been detected. improvements in traffic light managementas well as a small increase in overall performance measured as global throughput. Improved performance has also been observed in the context change between processes, an aspect that usually benefits systems with high concurrency.

Other benchmarks such as Hackbench, focused on the planner, have shown modest improvements in Linux 6.19 compared to 6.18. However, when moving from synthetic tests to workloads closer to the real world, the general trend at this stage of development is that Linux 6.19 Git behaves the same or slightly worse than the previous stable version.

Impact on desktop systems and file system stability in Linux 6.19-rc1

Aside from the servers, it has also been tested Linux 6.19 Git on a desktop with an AMD Ryzen CPUIn this case, the results have been more worrying in terms of stability: during testing, the following appeared file system errors that did not occur when reverting to stable Linux 6.18 on the same machine.

These types of desktop failures, although still under investigation, reinforce the idea that 6.19-rc1 and previous Git versions are not ready For general use outside of test or development environments, this is not recommended. For end users in Spain or Europe who value stability above all else, the reasonable recommendation remains to stay on the LTS or stable branch until these issues are contained and fixed.

It is planned that, once the turmoil of the integration window has passed and the code is more stabilized, the following will be carried out new test suites on more hardware, including the ability to perform "bisects" of the kernel to precisely locate the patches responsible for the most serious regressions.

New real-time clock (RTC) drivers for Apple and NVIDIA

Among the notable mergers that have entered Linux 6.19 before closing the window The changes to the real-time clock (RTC) subsystem are included here. While this is usually a relatively unobtrusive area, this update incorporates some notable new features for users of recent hardware.

On one hand, the “rtc-macsmc” driver for Apple SiliconOriginally developed by Hector Martin during his time leading the Asahi Linux project, this driver supports the RTC integrated into Apple's Power Management Unit (PMU), which is itself abstracted by the System Management Controller (SMC). The real-time counter is accessed through the SMCAnd this new driver gives Linux the ability to properly manage the clock on Apple's ARM-based Macs, similar to other support patches.

On the other hand, the premiere of “NVVRS” RTC driver for NVIDIA Tegra platforms on ARM64. This driver implements support for the real-time clock of NVIDIA's Voltage Regulator Specification (VRS), used in devices such as Jetson AGX Orin, IGX Orin, Jetson Orin NX and Jetson Orin NanoIts functions include system time management, preserving the time between restarts, and waking the computer from sleep or power-off states.

The RTC changelog for Linux 6.19 is completed with a New real-time clock driver for Andes ATCRTC100This expands the range of supported platforms. For European integrators and manufacturers working with embedded solutions or Jetson devices deployed in industry, robotics, or edge AI, these improvements facilitate more robust configurations that are aligned with current hardware.

LoongArch makes the leap to 32 bits with LoongArch32

In the architecture section, Linux 6.19 incorporates significant progress for LoongArchThe Chinese home CPU design inspired by MIPS and RISC-V. Until now, kernel support focused on LoongArch64 (64-bit), but with this version, the foundation for LoongArch32, the 32-bit variant.

Unlike the traditional market transition—where the shift has been from 32 to 64 bits—Loongson is taking the opposite step: 64 to 32 bitsIn Linux 6.19, the pieces of the LoongArch32 port began to be connected in the kernel, although the Build support is not yet enabled by default because some drivers are missing adjustments and it is necessary for the corresponding support in the GNU tool (binutils, GCC, etc.) to be fully implemented upstream.

LoongArch32 contempla two main variantsA reduced 32-bit version (LA32R) and a standard version (LA32/LA32S). In parallel, patches have already begun to be released for GCC to enable it. LoongArch32 target for GCC 16whose release is expected in early 2026. In addition, work continues on the rest of the toolchain, including debuggers and other components associated with LoongArch32 ABIs.

Also exist Patches to emulate LoongArch32 on LoongArch64 hardwareAlthough no specific references to LA32-only processors have been made public at the moment, this move is interpreted as a strategic step to offer more flexibility in product ranges and embedded scenarios, and positions Linux 6.19 as a key piece in the maturation of this alternative architecture.

Linux 6.19-rc1 now available for testing

With all these changes, Linux 6.19-rc1 is presented as a release candidate packed with new features: from that push for Rust and the improvements in driversFrom the new RTC drivers for Apple and NVIDIA, to the advancement in LoongArch32 and performance tests on the latest generation AMD EPYC hardware, the release has been a significant update. Despite the regressions detected in scheduling and networking, as well as some desktop stability issues, this new phase will serve to refine these aspects before the stable release planned for early February. At that point, administrators and users in Spain and Europe will be able to more confidently assess the transition to this new kernel.