Re: [PATCH] mm/thp: expose deferred split folio memory usage in meminfo
From: Lorenzo Stoakes (ARM)
Date: Fri Jul 17 2026 - 05:56:28 EST
On Fri, Jul 17, 2026 at 11:33:05AM +0200, David Hildenbrand (Arm) wrote:
> On 7/17/26 11:31, Ye Liu wrote:
> >
> >
> > 在 2026/7/17 16:37, David Hildenbrand (Arm) 写道:
> >> On 7/17/26 08:30, Ye Liu wrote:
> >>> From: Ye Liu <liuye@xxxxxxxxxx>
> >>>
> >>> Folios on the deferred split list hold physical memory that is
> >>> invisible in meminfo. When a THP becomes partially mapped, the
> >>> unmapped pages are removed from AnonPages but remain physically
> >>> allocated until the shrinker splits the folio. This creates a
> >>> memory accounting gap where used memory cannot be attributed to
> >>> any meminfo field.
> >>>
> >>> Add NR_DEFERRED_SPLIT_PAGES to track the total memory consumed by
> >>> folios currently on the deferred_split_lru, updated via
> >>> mod_node_page_state() at all enqueue/dequeue points. The new field
> >>> DeferredSplitPages is visible in /proc/meminfo, /proc/vmstat, and
> >>> per-node /sys/devices/system/node/node*/meminfo.
> >>>
> >>
> >> Oh no.
> >>
> >> This is really exposing a current implementation detail where we have this
> >> information easily available in a way that we will not be able to change that
> >> implementation later.
> >>
> >
> > Yes, `/proc/meminfo` is a user-space ABI.
> > Adding it there means you can't change the semantics,
> > and the field will become unmaintainable, yet you can't delete it either.
> > But I think this information is still necessary.
> > Where would be a better place to put it?
>
> Don't expose it to user space.
Yeah please stop.
We don't want this change, it exposes internal implementation details. It's a
no.
Next time send an RFC or a discussion thread.
>
> --
> Cheers,
>
> David
Thanks, Lorenzo