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

On Mon, Oct 12, 2026 at 12:36:35PM +0200, David Hildenbrand (Arm) wrote:

On 10/10/26 04:59, Yifan Li wrote:

quoted

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.

quoted

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.

quoted

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