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

[Isaac Manjarres]

On Mon, Sep 14, 2026 at 03:32:12PM -0700, Isaac Manjarres wrote:
> On Mon, Sep 14, 2026 at 01:29:06PM -0700, Isaac Manjarres wrote:
> > 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!
> > 
> I looked into this, and this works in reducing the overhead from number
> of syscalls, but the other part about correctness isn't handled by this.
> 
> For ringbuf maps we would have access to max_entries, but that just gives
> us the amount of memory consumed by the data portion of the ringbuf, but
> it doesn't include the 3 metadata (kernel structures, consumer idx page,
> and producer idx page). I don't see how to derive this value--rather
> than hardcoding it.
> 
> I did see that fdinfo for the maps does give the total memory usage
> via bpf_map_memory_usage(). However, that value includes structures that
> are allocated through the slab allocator and vmalloc, so using that
> value would double count the memory usage in the system. Userspace
> doesn't have the information required to break that value up to extract
> just the part that is allocated through alloc_pages() directly.
> 
> I think it's worthwhile accounting this data correctly, as on our setup
> there are 39 ringbufs. This can lead to 468 kB -- 1872 kB of unaccounted
> memory depending on the page size.
> 
> --Isaac
>
Please disregard my previous email. A colleague pointed out that I can
use bpf_core_type_size() to compute the size of the metadata that I was
referring to and that worked.

Thanks for all the help!
--Isaac