Profiling data for the compiler

Why this conversation

Most of what makes software fast or slow on modern hardware happens in the cache, and the layout of a data structure decides how well the cache is used. This is the second part of the conversation with Arnaldo Carvalho de Melo of Red Hat, maintainer of pahole and the perf tooling, recorded on the Wednesday afternoon at Open Source Summit Europe in Prague. Part one covers twenty years of pahole and how it became part of BPF’s infrastructure. This part picks up with a question about where things are going, and turns into a walk through profile-guided data structure layout.

The story of the week it was filmed is in Open Source Summit Europe 2026: who we met.

Rust, and fields that belong together

Rust seems to be the future, he says, even more so because it suits AI agents: the compiler constrains what you can do. In C you can do everything, including lots of bad things, and the result depends on the experience of the programmer. Rust is safe by default.

One detail of Rust matters for his work. The order in which you write a structure’s fields in the source is not guaranteed to be the order in memory. The compiler is free to reorganise the structure to use less memory, for example when a programmer has written a byte, then a short, then an integer, then a pointer, and alignment rules leave holes. Those holes were the reason for pahole in the first place. But Rust moves fields around without taking into account false sharing, or which fields are related to which.

Profiles for data, not only for code

The technique he is developing, now available in perf, closes that loop. You build the program, run it under a profiler, and the profiler looks at how memory is actually used. That information goes back to the compiler in a format it understands, and the compiler reorganises the structure again, this time based on real observations of which fields are used together.

Profile feedback to the compiler is not new for code. Projects such as Propeller watch which code paths are most common and have the compiler rearrange functions so that the rarely used parts move to the end, making better use of the first 64 bytes. What is new is doing the same for data structures. In the kernel, the structures that represent a process, a thread, a file or a network connection are completely internal, not part of the ABI, so they can be reorganised without breaking any contract.

perf already has support for data type profiling. He prototyped the integration that has perf produce type-resolved samples, but it is a long series, so he is sending it in chunks. A first batch of preparatory patches has been merged. “I could merge it myself,” he says, but he still goes through the process: submit to the mailing list, get reviews from other humans, address the comments, merge, and move to the next batch. He expected the initial prototype to be merged within a month or so.

Try it on your own workload

The how-tos describing the exact steps are public, so anyone can try it on the workload that matters to them: a database such as SQLite, PostgreSQL, MySQL or MariaDB, a compiler, a browser such as Chrome or Firefox, or the software a company runs on its own machines. That is also a way to get involved, by submitting feature requests and reporting problems. His presentation on the Plumbers website links to everything it mentions, such as CTF and instruction-based sampling on AMD processors.

Cache lines, not prefetching

The host compares it to prefetching. It is not quite that, he explains. Prefetching fetches cache lines ahead of a loop. This is about the line you are already bringing in: if you load 64 bytes because you access one field, the other bytes in that line should hold what you are about to access next. His example is a network connection, where several fields are read together to work out the size of the congestion window.

BPF beyond networking

When people hear BPF, he says, they think of networking. Tracing and security matter just as much. Security products need to intercept calls in the kernel to make decisions or detect attacks, and BPF lets them hook anywhere. With BPF LSM you do not reboot or recompile the kernel: you compile the bytecode, load it, and it passes verification. BPF started as the Berkeley Packet Filter. Eric Dumazet made it translate its instructions to native ones just in time instead of interpreting them, and from there people saw they could use it to extend the kernel in other ways.

The conversation ends on measurement. The host describes hardware at 400 and 800 gigabits, where thousands of transfers run in parallel and it is hard to see what is going on. Sampling costs performance, and BPF lowers that cost so much that continuous sampling becomes affordable where it was not before.