[RFC] bpf: account ring buffer backing pages separately from Lost RAM
Xiang Gao <[email protected]>
| Newsgroups | org.kvack.linux-mm,org.kernel.vger.bpf,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
Hi, I would like to discuss accounting BPF ring buffer backing pages in system-wide memory reports. BPF ring buffers allocate their data and metadata as order-0 pages directly from the buddy allocator, and then map those pages with vmap(). Because vmap() maps caller-owned pages, these backing pages are not counted by VmallocUsed. They are also not slab pages. As a result, most BPF ring buffer memory is not represented by an existing named /proc/meminfo category and appears as Lost RAM in Android memory reports. We measured this on an Android 6.18 kernel. Test case: 32 BPF ring buffer maps 16 MiB data area per map 512 MiB total data area Observed changes: Lost RAM: approximately +529 MiB VmallocUsed: approximately +2 MiB Slab: approximately unchanged After destroying all maps, the values returned close to baseline. The question is whether the kernel should expose the unique physical backing pages of live BPF ring buffers through a dedicated global counter and a /proc/meminfo entry, for example: BpfRingbuf: <value in kB> The proposed counter would include: * ring buffer data pages; * metadata pages; * consumer and producer position pages. It would exclude: * the second virtual mapping of data pages; * the pages[] pointer array; * map metadata allocations; * vmap page tables. The goal is to account for the currently unclassified direct backing pages. Slab- and vmalloc-backed auxiliary allocations are already represented by existing memory categories and should not be counted again. A possible implementation is an NR_BPF_RINGBUF vmstat counter maintained by the ring buffer allocation and free paths, with the aggregate exposed through /proc/meminfo. Questions: 1. Is a dedicated BPF ring buffer counter appropriate? 2. Should this be represented as an NR_* vmstat counter? 3. Is /proc/meminfo an acceptable interface for this information? 4. Is counting only unique physical backing pages the correct accounting unit? Thanks, Xiang Gao