Hash table memory usage and a BPF interpreter bug

Anton Protopopov led a short discussion at the 2025 Linux Storage, Filesystem, Memory-Management, and BPF Summit about amount of memory used by hash tables in BPF programs. He thinks that the current memory layout is inefficient, and wants to split the structure that holds table entries into two variants for different kinds of maps. When that proposal proved uncontroversial, he also took the chance to talk about a bug in BPF's call instruction.
Anton Protopopov 在 2025 年的 Linux 存储、文件系统、内存管理与 BPF 峰会上发起了一场简短的讨论，话题是 BPF 程序中哈希表占用的内存。他认为当前的内存布局效率不高，希望将存储表项的结构按不同类型的 map 拆分成两种变体。这个提议并未引发争议，于是他还借机讨论了一个与 BPF 调用指令相关的 bug。

Hash table memory use
哈希表的内存使用

Protopopov began with an explanation of the current structure of BPF hash tables. Each hashed bucket is a linked list of items; the table itself just stores a pointer to the first item in the list and a spinlock. Each item in the list is an htab_elem structure. This contains a hash of the key, a copy of the whole key, and two unions that are used in different ways by per-CPU and normal hash tables.
Protopopov 首先解释了当前 BPF 哈希表的结构。每个哈希桶是一个链表；哈希表本身只存储指向链表第一个元素的指针和一个自旋锁。链表中的每个元素是一个 htab_elem 结构，包含键的哈希值、完整键的副本，以及两个联合体，分别为 per-CPU 和普通哈希表提供不同的功能。

Half of the structure, 24 bytes, is only used by per-CPU BPF maps. Maps that are shared between CPUs are essentially wasting that space, Protopopov said. In a hash table with 100,000 elements, that's a total of about 2.4MB. To get some idea of ho