Re: [RFC PATCH 0/1] mm: page_frag: account page_frag pages in vmstat and meminfo

[Pedro Falcato <pfalcato@suse.de>]

On Mon, Oct 12, 2026 at 12:36:35PM +0200, David Hildenbrand (Arm) wrote:
> On 10/10/26 04:59, Yifan Li wrote:
> > This is an RFC.
> > 
> > Pages held by the page_frag cache are not accounted by any memory
> > statistics counter, so on systems that derive "LostRAM" as MemTotal
> > minus the sum of accounted memory they inflate LostRAM and lead to
> 
> Sorry, what exactly is subtracted from MemTotal?
> 
> How would any other kernel allocations be treated?

I suppose those would mostly show up as Slab:. But yes, I agree the metric
is a little dubious.

> 
> > misleading "leak" conclusions, even though the memory is legitimately
> > used by the network path.
> 
> Assuming "leak" in such scenarios is questionable, sorry.
> 
> Aren't most page_frag allocations short-lived? Or is this more about the
> page_frag cache?

page_frag allocations are kinda arbitrarily lived. If you queue (send) some
data to a socket to send over the wire, they are more likely than not
short-lived, unless the protocol/qdisc says no (for example, you're hitting
the TCP congestion window and as such can't send more data over the wire).
If you send it over loopback/veth you get arbitrarily livetimes as sockets
can keep the page frag alive if the application never reads them.

On the regular RX side you can also (AIUI) keep page frags randomly pinned
as long as you don't read them.

(note that all of these allocations are bounded by each protocol's memory
limits)


In any case, I remember an off-list discussion with mhocko regarding a
downstream bug, where I suggested adding a counter for this, and he said
networking is somewhat sensitive to extra accounting on the fast paths.
Added netdev in case they have comments.

> 
> > 
> > The page_frag allocator (page_frag_alloc / napi_alloc_frag /
> > netdev_alloc_frag) backs sk_buff->head and the frags portion of
> > skb_shared_info.  Unlike slab (NR_SLAB_*) or page_pool, page_frag
> > pages have no counter.  A preliminary measurement on a 4K-page
> > arm64 Android device shows 14432 kB (3608 pages) of page_frag
> > pages already in use at boot, and the memory footprint grows
> > larger under heavy load (e.g. sustained traffic through the
> > virtio_net / tun receive paths).
> > 
> > Patch 1/1 adds an NR_PAGE_FRAG node counter and exposes it as
> > nr_page_frag in /proc/vmstat and PageFrag in /proc/meminfo.  Pages
> > enter the cache through a single entry point
> > __page_frag_cache_refill(), so the increment side is complete; the
> > decrements sit on the paths that free the cache page.
> > 
> > The remaining gap is on the release side, which is open: a cache page
> > handed to an skb frags array (skb_add_rx_frag() /
> > skb_fill_page_desc(), without an extra get_page) is freed via
> > put_page() (kfree_skb -> __skb_frag_unref -> put_netmem -> put_page),
> > bypassing page_frag_free(), so the counter can over-count under
> > network load.
> > 
> > Closing that needs the page to carry a marker checked at the common
> > free path, e.g. either
> > 
> >   1. a page flag: PAGEFLAG(PageFrag, page_frag, PF_HEAD), accounted
> >      and cleared in __free_pages_prepare(); or
> > 
> >   2. a page type: PGTY_page_frag reusing _mapcount, accounted in
> >      free_frozen_pages() (requires that page_frag pages are never
> >      mapped into userspace; true for the current RX paths).
> > 
> 
> Certainly no page flag.
> 
> A page type might be the right choice. I don't think Willy planned for that [1],
> IIUC, the bump allocator was something different, but another page type
> shouldn't hurt at this point.

A page type might not work, these pages _may_ need to be mappable. I know
that was an issue for page_pool (Yet Another Networking Page Allocator) + TCP
zero-copy RX using mmap.

Of course, if you have a page frag under PAGE_SIZE or misaligned then you can't map that.

-- 
Pedro