Open Source Summit North America 2025

The Linux kernel project has been going for well over 30 years. From its beginnings on floppy diskettes and beige boxes through to its current home in pockets and unseen data centers, the kernel project has been a constant exercise in rapid development and adaptation. I have been present for almost all of the kernel project's history as an observer, contributor, maintainer, and more; all that experience will be boiled down into a fast-moving tour of how the kernel got to where it is, what makes it successful, and what may be coming next.

While containers provide isolation for CPU cycles and memory capacity, they offer limited protection against performance interference through shared CPU caches and memory bandwidth. Such contention was shown to increase application response times by 4-13x. The Linux resctrl infrastructure provides monitoring and control mechanisms, but has limitations for controlling real-world applications.

For example, new cgroups do not form new resctrl groups, leaving any newly started containers and systemd services improperly monitored and controlled. Additionally, the current filesystem-based interface makes it difficult to build a controller that can monitor and adjust quickly enough to keep up with frequently changing application memory behavior.

This talk introduces the memory interference problem and proposes new kernel mechanisms to address these limitations. A new collector captures per-process measurements of memory bandwidth usage at millisecond frequencies. We'll cover how the collector combines eBPF, high-resolution timers, and perf counters to achieve this, and how resctrl can be supported in this framework. We'll discuss future work and opportunities for collaboration.

We present the Rex project (https://github.com/rex-rs/rex). Rex is a Linux kernel extension framework that allows extension programs to be written in safe Rust. Rex offers similar safety guarantees to eBPF. Unlike eBPF-based tools like Aya, Rex extensions are not compiled into eBPF bytecode. Rex eliminates the in-kernel verifier – the safety of Rex extensions is built atop language-based safety plus runtime protection. Specifically, the Rex compiler enforces Rex extensions to be written in a subset of safe Rust, and emits native code directly. Rex implements its kernel crate with a safe interface that wraps existing eBPF interface. Rex also employs a lightweight runtime that implements graceful Rust panic handling with resource cleanups, kernel stack checks, and program termination.

Rex provides a more usable and arguably safer alternative to eBPF. The usability advantage comes from the elimination of in-kernel verifiers that are known to reject safe extension programs with cryptic feedback. We also show that Rex’s runtime protection provides stronger safety than eBPF in a few aspects, e.g., protecting kernel stacks from overflowing.

More details: https://tinyurl.com/y8uj8ypp

The vmalloc mechanism in the Linux kernel provides contiguous virtual memory allocations, even when the underlying physical memory is non-contiguous. However, with increasing adoption and usage, the synchronization of vmalloc data structures poses significant performance challenges, particularly in many-core systems with 256+ cores.

This session will explore the scalability improvements made to the vmalloc mechanism, covering the following key topics:

1. An overview of the legacy vmalloc approach, which relies on a single global lock for data synchronization.

2. Introduction to an enhanced vmap node implementation designed to address the limitations of the legacy approach.

3. Identification and detailed analysis of two remaining performance bottlenecks despite the enhanced vmap node implementation, along with their proposed solutions.

Join us to gain insights into the evolving design of vmalloc and its implications for performance in modern high-core-count systems.

Ever wonder how a bug fix lands on the kernel you are running on your system?

Would you like to know how to effectively get such fixes in the hands of most users?

From the time it gets submitted for review until an update is available in a distro, a lot of processes need to be followed and many people are involved.

The talk will go over some of these processes, some of the obstacles that may get in the way and how to make it easier for the people who do the work to get these fixes into the hands of as many people as possible.