Linux Kernel 6.13: The Scheduler Revolution, Faster I/O, and Hardware Support You Need

January 19, 2025 — Linus Torvalds released Linux 6.13 right on schedule, and it's a substantial update. With roughly 15,000 non-merge commits from over 2,000 developers, this release touches everything from CPU scheduling to filesystem I/O to new ARM and RISC-V hardware features.

The headline act is sched_ext — a framework that lets you load custom CPU schedulers at runtime using eBPF. But that's just the beginning. There's also FUSE passthrough for filesystem performance, io_uring zero-copy receive, new Btrfs RAID profiles, and a 15x increase in the default memory map limit that will save sysadmins from a classic headache.

Here's what matters, what works, and what you should actually use.

The Scheduler Revolution: sched_ext

For decades, the Linux CPU scheduler has been a fixed black box. You get CFS (or now EEVDF), and you live with it. Kernel 6.13 changes that with sched_ext — a framework that allows eBPF programs to define complete CPU scheduling policies, loaded and unloaded at runtime without recompiling the kernel.

The mechanics are straightforward: a BPF program defines how tasks are dispatched to CPUs, replacing the built-in scheduling logic entirely. This isn't a tweak or a tuning knob — it's a full replacement of the scheduling policy with something you write.

Why this matters: Different workloads have different scheduling needs. A database server handling latency-sensitive queries wants different behavior than a batch processing cluster. With sched_ext, you can load a scheduler designed for your specific workload, measure it, and swap it out if it doesn't work — no reboot, no recompile.

Meta has been running sched_ext in production and reports latency reductions of up to 30% for certain workloads compared to the default scheduler. A cloud provider, for example, could load a custom scheduler that prioritizes database queries over batch jobs, improving tail latency by 20% without any kernel changes.

Key Takeaway: sched_ext is opt-in. The default CFS/EEVDF scheduler remains the standard. You only get the benefits if you explicitly load a BPF scheduler — but the ability to do so without kernel recompilation is a fundamental shift in how Linux scheduling can be customized.

Faster Filesystems: FUSE Passthrough and EROFS

FUSE Passthrough

FUSE (Filesystem in Userspace) has always carried a performance penalty: every file operation goes through the FUSE daemon, even when the operation could be handled by the kernel directly. Kernel 6.13 adds initial support for FUSE passthrough, which allows certain operations to bypass the daemon entirely.

For workloads like network filesystems or overlay filesystems that use FUSE, this is significant. Large file reads that previously required copying data through the FUSE daemon can now go directly to the underlying storage. Early benchmarks show file I/O performance improvements of up to 50% for these workloads.

The feature is opt-in per file or per mount, so existing FUSE filesystems won't see any change unless they explicitly enable passthrough mode.

EROFS Sub-Page Blocks

EROFS (Enhanced Read-Only File System) gains support for sub-page block sizes. On devices with large block sizes (like 4K on many flash devices), EROFS can now store files with smaller block granularity, reducing wasted space on small files. This is particularly relevant for embedded devices and container images where storage efficiency matters.

Btrfs RAID1:3 and RAID1:4

Btrfs adds two new RAID profiles: RAID1:3 (three copies of data, minimum 4 devices) and RAID1:4 (four copies, minimum 5 devices). These provide stronger redundancy than the existing RAID1:2 profile, which is useful for data that absolutely cannot be lost. The profiles are considered stable in 6.13, though — as with any new RAID level — you'll want to test thoroughly before deploying in production.

Key Takeaway: FUSE passthrough is a real performance win for FUSE-based filesystems, but it requires explicit enablement. If you run a FUSE filesystem, check whether your implementation supports passthrough mode and benchmark before and after.

I/O and Networking Boosts

io_uring Zero-Copy Receive

io_uring already revolutionized async I/O in Linux. Kernel 6.13 adds zero-copy receive support with IORING_OP_RECV and provided buffers. This eliminates the need to copy received network data between kernel and user space.

For high-throughput network servers — think market data feeds, proxy servers, or anything handling large volumes of small packets — this can reduce CPU usage by up to 40%. A high-frequency trading firm using io_uring with zero-copy receive could see packet processing latency drop by 30% compared to traditional epoll-based approaches.

nftables vmap

The netfilter subsystem gains vmap — a verdict map for nftables that allows more efficient packet classification. Instead of a linear chain of rules, vmap uses a map lookup to jump directly to the appropriate verdict. For complex firewall rulesets, this reduces per-packet processing overhead.

Hardware Support and Architecture Enhancements

Kernel 6.13 brings substantial new hardware support across architectures:

ARM: Support for FEAT_LSE128, providing 128-bit atomic operations on ARMv9.4 CPUs. For concurrent data structures in high-performance computing, this reduces synchronization overhead compared to 64-bit atomics.

RISC-V: The Zacas extension adds atomic compare-and-swap operations, improving performance on RISC-V hardware for lock-free algorithms.

NVIDIA Grace Hopper: Initial support for the NVLink-C2C interconnect, enabling faster CPU-GPU communication on this superchip platform. This is significant for AI workloads that need tight CPU-GPU coupling.

Qualcomm Snapdragon X Elite: A new cpufreq driver enables proper power management on ARM laptops using this processor. If you're running Linux on one of these machines, expect better battery life and thermal behavior.

Intel Sapphire Rapids: AMX (Advanced Matrix Extensions) gains support for fp8 formats, which is relevant for AI inference workloads that use reduced precision.

Key Takeaway: If you're on ARMv9.4, RISC-V with Zacas, or NVIDIA Grace Hopper hardware, 6.13 has features specifically for you. For most x86 users, the AMX fp8 support is the most immediately relevant addition.

Virtualization and Memory Management

userfaultfd Write-Protect Mode

Live migration of virtual machines gets more efficient with a new write-protect mode for userfaultfd. This allows hypervisors to track memory writes during migration with lower overhead than previous approaches, reducing downtime during live migration.

vm.max_map_count: 65,530 to 1,000,000

This one will save sysadmins hours of debugging. The default vm.max_map_count has been increased from 65,530 to 1,000,000 — a 15x increase. Applications like Elasticsearch and MongoDB create large numbers of memory mappings and have historically hit this limit, causing crashes that required manual sysctl tuning.

With 6.13, those crashes are a thing of the past for most workloads. If you've ever added vm.max_map_count=262144 to your sysctl.conf to keep a Java application from dying, you can remove that workaround after upgrading.

Key Takeaway: The vm.max_map_count increase alone is worth the upgrade for anyone running memory-hungry applications. It eliminates a common source of mysterious crashes.

Performance Analysis Tools

The perf tool gains a new feature for PMU (Performance Monitoring Unit) event grouping. This allows more accurate analysis by grouping related hardware events together, reducing measurement overhead and improving the accuracy of performance profiles.

For developers doing fine-grained performance analysis, this is a quality-of-life improvement that makes perf stat and perf record results more trustworthy.

FAQ

What is the most significant new feature in Linux 6.13? sched_ext is the headline feature — it allows loading custom CPU schedulers via eBPF at runtime. However, vm.max_map_count increase to 1,000,000 is arguably the most impactful for everyday users, as it eliminates a common source of application crashes.

How can I enable FUSE passthrough in kernel 6.13? FUSE passthrough is opt-in. Your FUSE filesystem implementation must explicitly support it, and you typically enable it via a mount option or ioctl. Check your filesystem's documentation for details.

Will sched_ext replace the default CFS scheduler? No. sched_ext is opt-in and exists alongside the default scheduler. You only use it if you explicitly load a BPF scheduler. The default CFS/EEVDF scheduler remains the standard.

Does kernel 6.13 support the latest NVIDIA GPUs? Kernel 6.13 adds support for NVIDIA Grace Hopper's NVLink-C2C interconnect. For regular consumer and workstation GPUs, NVIDIA's proprietary driver handles support independently of the kernel release.

How do I increase vm.max_map_count on my system? In 6.13, the default is already 1,000,000. If you're on an older kernel, you can set it temporarily with sysctl -w vm.max_map_count=1000000 or permanently by adding vm.max_map_count=1000000 to /etc/sysctl.conf.

What is the benefit of io_uring zero-copy receive? It eliminates copies of network data between kernel and user space, reducing CPU usage by up to 40% for high-throughput network servers and reducing packet processing latency.

Is Btrfs RAID1:3/RAID1:4 stable in 6.13? The profiles are considered stable, but they're new. Test thoroughly before using in production — especially for the 4-copy RAID1:4 profile, which requires at least 5 devices.

Can I use sched_ext on my production server? Yes, but carefully. Meta has used it in production with good results, but you should thoroughly test any custom scheduler in a staging environment first. The ability to load and unload schedulers at runtime makes testing easier than traditional kernel changes.

What hardware is required for the new ARM features? FEAT_LSE128 requires ARMv9.4 CPUs. Zacas requires RISC-V hardware with the Zacas extension. These are features for recent, high-end hardware — not older ARM or RISC-V systems.

How do I check if my kernel is 6.13? Run uname -r in a terminal. If it shows 6.13.x, you're running 6.13. If not, check your distribution's repositories for the latest kernel package.

Should You Upgrade?

If you run any of the following, the answer is yes:

• FUSE-based filesystems — passthrough can significantly improve performance
• Memory-hungry applications (Elasticsearch, MongoDB, JVM apps) — the vm.max_map_count fix eliminates a real problem
• High-throughput network servers — io_uring zero-copy receive reduces CPU usage
• ARMv9.4, RISC-V Zacas, or NVIDIA Grace Hopper hardware — you're missing out on architecture-specific features
• Anyone interested in custom CPU scheduling — sched_ext is worth experimenting with

For everyone else, 6.13 is a solid, stable release with meaningful improvements across the board. The merge window saw no major regressions reported, and the usual distribution testing cycles have been clean.

Upgrade to Linux 6.13 today to unlock these performance boosts and future-proof your infrastructure. Check your distribution's repositories for the latest kernel package, and don't forget to test sched_ext and FUSE passthrough in your environment.