BPF continues to be the rising star of Linux tracing and I think that we should evaluate its suitability in an HPC context to have a clear answer for the next time "I could use BPF for that" comes up.

I think BPF is inevitable for two reasons:

1. Having read access to kernel memory is an absolute killer feature, especially considering much of the useful information in tracepoints is hidden behind pointers to kernel memory.
2. It feels like BPF is quickly leaving behind more traditional tracing approaches using perf and the lot, with the answer more often becoming "Just throw BPF at it"/

However, in the past BPF has been very "move fast and break things" which is unsuitable for HPC. Compiled BPF programs especially were not portable between kernel releases as when kernel data structures changed, BPF programs accessing those data structures would tend to break.

However, CO-RE has emerged as a mechanism for supporting portable BPF programs using clever symbol resolution magic and has now been in the kernel for quite some time.

This leaves us with the following tasks

• Evaluate CO-RE support on our target systems
• Evaluate the overhead of BPF
• Evaluate permission requirements.