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

["David Hildenbrand (Arm)" <david@kernel.org>]

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?

> 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?

> 
> 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.

[1] https://kernelnewbies.org/MatthewWilcox/Memdescs

-- 
Cheers,

David