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

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

On 10/12/26 13:27, Pedro Falcato wrote:
> 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.

That makes sense.

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

I'll have to trust on networking experts, I was reading:

	 (requires that page_frag pages are never
     mapped into userspace; true for the current RX paths).

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

It would be best if we could disallow that entirely :)

(of if required, map them through a PFNMAP or similar that does not care about
page metadata ... but the interactions with GUP are tricky)

-- 
Cheers,

David