为什么用户空间应用程序要锁定 Ebpf 映射？答案

【问题标题】：Why should userspace applications lock Ebpf maps?为什么用户空间应用程序要锁定 Ebpf 映射？
【发布时间】：2021-10-28 05:42:46
【问题描述】：

当您创建 EBPF 映射时，内存是在内核空间中分配的。并且内核内存永远不会被换出。那么，为什么用户空间应用程序需要调用setrlimit() 和RLIMIT_MEMLOCK？

【问题讨论】：

标签： linux-kernel bpf ebpf

【解决方案1】：

RLIMIT_MEMLOCK 是指可以锁定在 RAM 中的内存量，它并不特定于用户空间内存地址范围内的分配。在 5.11 之前的内核中，用于 eBPF 对象（程序、映射、BTF 对象等）的内存是针对该资源计算的，这意味着如果您在给定时间甚至在很短的时间间隔内创建了太多的对象（考虑到在内核回收相应的内存区域之前删除对象后有一小段延迟），您可能会达到资源限制并得到-EPERM作为答案。对于特权用户，调用setrlimit() 解除对该资源的限制确实是通常的解决方法。

请注意，在 Linux 5.11 中，rlimit-based accounting was dropped in favour of cgroup-based memory accounting。 rlimit 有许多缺点（有关详细信息，请参阅上面链接的求职信），基于 cgroup 的记帐更加灵活，同时允许更好的控制并提供更简单的方法来检索当前使用的内存量。它还应该反映实际的内存消耗，而 rlimit 不一定是这种情况。

【讨论】：

谢谢。 1. ebpf 上的 libbpf mlock() 是否映射内存区域？ 2. 如果是，为什么会这样？映射驻留在内核内存中，因此它们永远不会被换出，这意味着不需要 mlock() 调用。我知道 setrlimit() 有助于增加 mlock() 的上限。但是，我不明白为什么首先应该用户空间应用程序 mlock() 内核页面。
不，libbpf 不 mlock() 映射内存区域（除了一些特定的用例）。但这与用户空间的作用无关。一旦用户在 Linux RLIMIT_MEMLOCK 检查总数。与在对象上运行 mlock() 的用户空间无关。在这种情况下，限制的名称具有误导性。