Kernel: Linux 6.10, GitLab, and 2024 Linux Storage, Filesystem, Memory-Management and BPF Summit
-
The first half of the 6.10 merge window
The merge window for the 6.10 kernel release opened on May 12; between then and the time of this writing, 6,819 non-merge commits were pulled into the mainline kernel for that release. Your editor has taken some time out from LSFMM+BPF in an attempt to keep up with the commit flood. Read on for an overview of the most significant changes that were pulled in the early part of the 6.10 merge window.
-
GitLab CI for the kernel
Working on the Linux kernel has always been unlike working on many other software projects. One particularly noticeable difference is the decentralized nature of the kernel's testing infrastructure. Projects such as syzkaller, KernelCI, or the kernel self tests test the kernel in different ways. On February 28, Helen Koike posted a patch set that would add continuous integration (CI) scripts for the whole kernel. The response was generally positive, but several people suggested changes.
Koike's patch set adds a new top-level ci directory that contains YAML configuration files for GitLab's continuous-integration feature, as well as shell scripts to tie those to the existing kernel tests. It reuses some of her existing work from the kernel's graphics subsystem tests, which also use GitLab as a Continuous Integration platform. The patch set currently includes code to run checkpatch and Smatch against proposed patches, and attempt to build the kernel on a few different architectures, but Koike plans to expand the coverage if this initial work is accepted. The patch set also includes a top-level .gitlab-ci file that instructs GitLab to run the tests by default.
- An update and future plans for DAMON: DAMON and DAMOS provide a toolkit for the control of memory-reclaim policies from user space. DAMON author SeongJae Park updated the group on recent developments in this subsystem and talked about where it is going next.
- Extending the mempolicy interface for heterogeneous systems: the kernel's memory-policy API has not kept pace with hardware changes; how can that be fixed?
- Better support for locally attached memory tiering: CXL memory holds out the promise of significant cost savings, but only if the kernel can manage it properly.
- What's next for the SLUB allocator: the current and future status of the kernel's one remaining object allocator.
- Facing down mapcount madness; managing the mapping count of pages is trickier than it seems, but the situation is being improved.
- Dynamically sizing the kernel stack: kernel stacks are simultaneously too small and too big; making their size variable would solve that problem.
- Memory-allocation profiling for the kernel: a once-contentious discussion on this new feature refocuses on future improvements.
- Another try for address-space isolation: mitigations for hardware vulnerabilities have cost us a lot of performance; address-space isolation offers protection against present and future vulnerabilities while giving us that performance back.
- Faster page faults with RCU-protected VMA walks: the faster way to search through the VMA tree.
- Toward the unification of hugetlbfs: the hugetlbfs subsystem is arguably an outmoded way of accessing huge pages that imposes costs on memory-management maintenance. Coalescing it into the core will help, but it will not be an easy job.
- Merging msharefs: this proposal to allow the sharing of page tables between processes has been under consideration for some time; what is needed to get it upstream?
- Documenting page flags by committee: an attempt at large-scale collaborative authoring.
- Two sessions on CXL memory: Compute Express Link is promoted as a boon to data-center computing; two sessions looked at how the kernel can support this functionality.
- The path to deprecating SPARSEMEM: the kernel has several ways of representing physical memory; one of them may be on its way out.
- A plan to make BPF kfuncs polymorphic: a proposal that would allow kfuncs to use different implementations depending on where and how they are called.
- Virtual machine scheduling with BPF: a talk about solving the "double scheduling" problem for virtual machines.
- The interaction between memory reclaim and RCU: the reclaim process can be accelerated by using the read-copy-update mechanism to avoid locking, but there are still some problems to work out.
- Supporting larger block sizes in filesystems: another discussion of what needs to be done for filesystems in order to support block sizes larger than 4KB.