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

[Isaac Manjarres]

On Fri, Sep 11, 2026 at 05:04:55PM -0700, Andrii Nakryiko wrote:
> On Fri, Sep 11, 2026 at 4:24 PM Isaac Manjarres
> <isaacmanjarres@xxxxxxxxxx> wrote:
> >
> > On Wed, Aug 19, 2026 at 10:24:28AM -0700, Andrii Nakryiko wrote:
> > > 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.
> > >
> > Hi Andrii,
> >
> > Thanks for the suggestion on this! I did want to express a couple of
> > concerns with this:
> >
> > Scalability
> >
> > I counted the number of maps on one of our devices, and there are 112
> > maps, meaning that there will be between 224-336 syscalls with this
> > approach. eBPF is becoming more popular, so I'm concerned about how well
> > this will scale, if we have to invoke 2-3 syscalls per map.
> >
> > I had a test program that implemented your suggestion, and it took about
> > 2 ms to identify 39/112 ringbufs. As the number of maps in the system
> > grows, I'm concerned that the latency associated with computing the
> > memory usage from ringbufs will become even more expensive. This is
> > something we had an issue with before on Android, where we had to
> > iterate through various sysfs files to gather wakeupsource metrics [1].
> >
> > To improve on this, I was wondering if we could expose the ringbuf
> > memory usage and potentially other bpf stats through bpffs
> > (/sys/fs/bpf/stats)? This counter could be a lightweight counter that is
> > incremented/decremented on ringbuf allocation/freeing so that when it is
> > read, there aren't any expensive computations.
> >
> > For this specific metric, we could just use a counter to track how much
> > memory is being used by ringbufs and have userspace read that. That also
> > brings me to my next point.
> >
> 
> I just don't see a good enough reason to single out ringbuf maps
> specifically. other map types also use memory, why would they be
> excluded?

I was looking at ringbuf maps specifically because they allocate memory
for the ringbuf via alloc_pages() and aren't attributed to any counter
that is exposed to userspace. The other maps use either the slab
allocator or vmalloc() to allocate memory, and those entries are visible
via /proc/meminfo.

> If you are worried about too many syscalls, look into map iterator
> program types (grep for SEC("iter/bpf_map") in selftests). That will
> be super fast and way more generic than what you propose. You can ping
> such program in bpffs and that will be you custom /sys/fs/bpf/stats
> implementation that you have full control and customizability of
> 

Thanks for the suggestion; I'll look into this and let you know if I
have any questions!

--Isaac