OSS + ELC EU 2026

This talk will cover several memory management concepts and underlying principles to give the audience a better understanding about what happens to the RAM on a Linux system, and how to determine that on their own system, namely:

- how much memory is used by userspace processes, the page cache, and the kernel itself
- how to determine accurately how much memory is used by individual processes
- why free memory is always eventually exhausted and what happens then
- how to observe what the kernel is doing to make memory available for allocations, and recognize when it's struggling
- what is the role of swap and why not fear swapping

This includes explaining some key parts of files like /proc/meminfo and /proc/vmstat.

While Continuous Integration (CI) has become a standard for most software projects via platforms like GitHub, testing massive, highly complex repositories like the Linux kernel has traditionally required bespoke environments. This limitation creates significant friction for new kernel contributors, out-of-tree module maintainers, and low-level system library authors attempting to validate compatibility against the latest development branches.

This session details a practical architecture for running the latest development kernels entirely within commodity CI environments. There are two key components: a highly optimized, VM-tuned kernel configuration, and vmtest, an open-source utility that abstracts away the complexities of QEMU configuration, seamlessly maps the CI workspace as the virtual machine's root filesystem via the 9P protocol, and propagates test command return codes back to the runner.

By the end of the session, attendees will gain the knowledge to build custom kernel CI workflows, leaving with a boilerplate GitHub Actions .yml from danobi/vmtest-action-demo to immediately deploy their own testing pipelines.

Memory efficiency problems are notoriously hard to see. DAMON was built to change that — but many users collect data incorrectly, visualize it poorly, and walk away with wrong conclusions. The tool gets blamed. The real problem goes unfixed.

This talk shows you the right ways to do it.

We cover data collection first: configuring sampling and aggregation parameters, the tradeoffs, and setup mistakes that corrupt your data before analysis begins.

We then walk through the visualization features in `damo` — heatmaps of access frequency across time and address space, working set size plots, and more. There is no single right visualization; we cover when to use each and how to read what it shows.

We also highlight mistakes that lead users astray: misreading sampling artifacts as real patterns, choosing granularities that hide behavior, observing too briefly to catch periodic patterns, and more. For each, we show what misleading output looks like and how to fix it.

By the end, you will know how to collect trustworthy DAMON data, pick the right visualization, and tell when your results are real versus when your setup is lying to you.

Linux dominates modern infrastructure, yet its monopoly on hardware support and application ecosystems creates a false premise, that Linux is the only viable platform. FreeBSD has quietly built two production grade compatibility layers that challenge this assumption.
LinuxKPI implements Linux kernel APIs directly inside the FreeBSD kernel, enabling unmodified GPU, wireless, and RDMA drivers including but not limited to amdgpu, iwlwifi, and Mellanox OFED to compile and run natively. Contrary too emulation this is source-level API compatibility with negligible runtime overhead.
The Linuxulator complements this at the userland boundary which is a high-performance syscall translation layer that executes unmodified Linux ELF binaries on the FreeBSD kernel, with measured overhead consistently under 2% for I/O-bound workloads.
Combined with FreeBSD Jails and VNET, operators gain isolated Linux environments with native ZFS storage, DTrace observability, and a hardened network stack without a hypervisor.
This talk examines the architecture of both layers, their production deployment patterns, and the upstream contribution model that keeps them current with Linux kernel releases.

Linux has steadily evolved toward Maple Tree as the preferred infrastructure for range-based indexing. While Maple Tree transformed process address-space management, several core memory-management subsystems still rely on legacy rb-tree-based designs.

This session uses the my vmalloc Maple Tree migration patch series as a case study to explore a broader question: what does it take to modernize a mature memory-management subsystem at the heart of the Linux kernel?

Unlike VMAs, vmalloc combines range allocation, gap tracking, coalescing, and lazy reclamation used by drivers, architectures, modules, and core kernel services. More than a data-structure replacement, it demonstrates how foundational kernel infrastructure can evolve while preserving correctness and long-standing semantics.

The talk covers the design motivations behind the transition, key trade-offs between augmented rb-trees and Maple Tree, scalability and metadata-efficiency improvements, and lessons learned from modernizing a core allocator. Attendees will gain insight into vmalloc internals, Maple Tree adoption beyond VMAs, and practical approaches for evolving Linux memory management infrastructure.

Your AI agent just wrote some code and wants to run it on your machine. It can read your SSH keys, exfiltrate data to any host, and overwrite your project. How do you give it just enough freedom to be useful, and nothing more?

This talk presents Sandlock, an AI agent sandbox for Linux that locks a process down in about 5 milliseconds using nothing but the kernel. No root. No cgroups. No containers. Spinning up a container or microVM per agent action means image builds, privileged setup, and a ~100 ms tax on every launch. Sandlock makes confinement cheap enough to wrap every command an agent runs.

We will show how it composes three kernel features: Landlock for filesystem, network, and IPC scoping; seccomp-bpf for syscall filtering; and seccomp user notification, where a supervisor enforces memory limits, an IP and port allowlist, HTTP-level ACLs with zero-config HTTPS inspection, and a copy-on-write working directory.

Live demos: pin an agent's egress to a single API, give it data access but no network, preview every file it would change before committing, and see real numbers (44x faster startup than Docker).