Re: [External Mail]Re: [RFC] bpf: account ring buffer backing pages separately from Lost RAM

[Andrii Nakryiko]

On Tue, Aug 18, 2026 at 6:46 AM 高翔 <gaoxiang17@xxxxxxxxxx> wrote:
>
> Thanks for the pointer. Understood — no new NR_* counter or
> /proc/meminfo entry.
>
>
> The remaining question is on the consumer side: Android's Lost RAM
> accounting would need to enumerate all live BPF ringbuf maps
> (BPF_MAP_GET_NEXT_ID) and read each map's fdinfo memlock to sum them.
>

For BPF ringbufs specifically, you should be fine just iterating all
map with BPF_MAP_GET_NEXT_ID, getting its FD with
BPF_BTF_GET_FD_BY_ID, and then passing that fd to
BPF_OBJ_GET_INFO_BY_FD to get map's size.

>
> Is per-map fdinfo enumeration the intended way for userspace to get the
> aggregate, or is there a more efficient BPF-specific aggregate interface
> that I'm missing?
>



>
> ________________________________
> 发件人: Andrii Nakryiko <andrii.nakryiko@xxxxxxxxx>
> 发送时间: 2026年8月18日 2:22:07
> 收件人: David Hildenbrand (Arm)
> 抄送: Xiang Gao; Andrii Nakryiko; Alexei Starovoitov; Daniel Borkmann; Andrew Morton; 印闯; bpf@xxxxxxxxxxxxxxx; linux-mm@xxxxxxxxx; linux-fsdevel@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; 高翔; Lorenzo Stoakes (Arm); Steven Rostedt
> 主题: [External Mail]Re: [RFC] bpf: account ring buffer backing pages separately from Lost RAM
>
> [外部邮件] 此邮件来源于小米公司外部，请谨慎处理。若对邮件安全性存疑，请将邮件转发给misec@xxxxxxxxxx进行反馈
>
> On Mon, Aug 17, 2026 at 11:10 AM David Hildenbrand (Arm)
> <david@xxxxxxxxxx> wrote:
> >
> > On 8/15/26 11:18, Xiang Gao wrote:
> > > Hi,
> >
> > 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().
> >
> > I assume there is a reason the slab isn't used, right? Are these pages mapped
> > into user space such that page->mapcount would get used?
> >
> > Can you point me at relevant code?
>
> See code in [0]. And yes, these pages are meant to be mapped into user space.
>
>   [0] https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git/tree/kernel/bpf/ringbuf.c#n93
>
> >
> > >
> > > 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>
> >
> > This looks a bit too specific for my taste. And I think we should try to no
> > inflate these statistics here too much.
> >
>
> +1, way too specific
>
> > >
> > > 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?
> >
> > I don't think so.
> >
> > See [1] where we just had the same discussion for tracing buffers. For them,
> > Steve [2] had an idea on how to expose them more fine-grained and tracing specific.
> >
> > [1] https://lore.kernel.org/r/20260810094025.136705-1-gaoxiang17@xxxxxxxxxx
> > [2] https://lore.kernel.org/r/20260810105710.6ee5e493@xxxxxxxxxxxxxxxxxx
> >
>
> We already report per-BPF ringbuf memory usage either through bpf()
> syscall or map's fdinfo. E.g., with `sudo bpftool map show` you'll
> see"
>
> 1455733: ringbuf  name event_ringbuf  flags 0x0
>         key 0B  value 0B  max_entries 262144  memlock 275776B
>         btf_id 2193434
>         pids tcpeventd(2549812)
>
> where memlock is how much memory is allocated for the ringbuf data area.
>
> > > 2. Should this be represented as an NR_* vmstat counter?
> >
> > I don't think so.
> >
> > > 3. Is /proc/meminfo an acceptable interface for this information?
> >
> > Again, I don't think so. "Lost RAM" really is just "excessive memory allocated
> > by some other subsystem".
> >
> > I agree that some users might want to figure out what is consuming that much
> > memory, but I don't think growing /proc/meminfo in that way is really what we want.
> >
> > > 4. Is counting only unique physical backing pages the correct accounting unit?
> >
> > I'd assume the "It would exclude" part above should not be accounted there, if
> > that's what you mean.
> >
> > --
> > Cheers,
> >
> > David