[RFC] bpf: account ring buffer backing pages separately from Lost RAM
From: Xiang Gao
Date: Sat Aug 15 2026 - 05:19:32 EST
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