All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ye Liu <ye.liu@linux.dev>
To: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>,
	"David Hildenbrand (Arm)" <david@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Danilo Krummrich <dakr@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Ye Liu <liuye@kylinos.cn>, "Liam R. Howlett" <liam@infradead.org>,
	Vlastimil Babka <vbabka@kernel.org>,
	Mike Rapoport <rppt@kernel.org>,
	Suren Baghdasaryan <surenb@google.com>,
	Michal Hocko <mhocko@suse.com>, Kairui Song <kasong@tencent.com>,
	Qi Zheng <qi.zheng@linux.dev>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	Barry Song <baohua@kernel.org>,
	Axel Rasmussen <axelrasmussen@google.com>,
	Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
	Zi Yan <ziy@nvidia.com>,
	Baolin Wang <baolin.wang@linux.alibaba.com>,
	Nico Pache <npache@redhat.com>,
	Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
	Lance Yang <lance.yang@linux.dev>,
	Usama Arif <usama.arif@linux.dev>,
	driver-core@lists.linux.dev, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] mm/thp: expose deferred split folio memory usage in meminfo
Date: Fri, 17 Jul 2026 17:54:55 +0800	[thread overview]
Message-ID: <41bc5ca5-08ed-4aba-86a3-d7f44b16e6f5@linux.dev> (raw)
In-Reply-To: <aln6SBHcxBY-9Vfl@lucifer>



在 2026/7/17 17:48, Lorenzo Stoakes (ARM) 写道:
> 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@kylinos.cn>
>>>>>
>>>>> 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.
> 
Yes, sending an RFC would be more appropriate.                                                  
                                                                                                
I'd also like to ask if it's possible to implement this in                                      
`/sys/kernel/debug/deferred_split_pages`, or are you completely against querying this statistic?
                                                                                                
How can we quickly identify this situation?                                                     
I believe some people will still be confused: where did the memory go?                          

>>
>> --
>> Cheers,
>>
>> David
> 
> Thanks, Lorenzo

-- 
Thanks,
Ye Liu


  reply	other threads:[~2026-07-17  9:55 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-17  6:30 [PATCH] mm/thp: expose deferred split folio memory usage in meminfo Ye Liu
2026-07-17  8:08 ` Lorenzo Stoakes (ARM)
2026-07-17  9:24   ` Ye Liu
2026-07-17  9:38     ` liuye
2026-07-17  9:47       ` Lorenzo Stoakes (ARM)
2026-07-17 10:29       ` Johannes Weiner
2026-07-17  8:37 ` David Hildenbrand (Arm)
2026-07-17  8:47   ` Lorenzo Stoakes (ARM)
2026-07-17  9:31   ` Ye Liu
2026-07-17  9:33     ` David Hildenbrand (Arm)
2026-07-17  9:48       ` Lorenzo Stoakes (ARM)
2026-07-17  9:54         ` Ye Liu [this message]
2026-07-17 10:29           ` David Hildenbrand (Arm)
2026-07-17 10:29     ` Vlastimil Babka (SUSE)

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=41bc5ca5-08ed-4aba-86a3-d7f44b16e6f5@linux.dev \
    --to=ye.liu@linux.dev \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=dakr@kernel.org \
    --cc=david@kernel.org \
    --cc=dev.jain@arm.com \
    --cc=driver-core@lists.linux.dev \
    --cc=gregkh@linuxfoundation.org \
    --cc=kasong@tencent.com \
    --cc=lance.yang@linux.dev \
    --cc=liam@infradead.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=liuye@kylinos.cn \
    --cc=ljs@kernel.org \
    --cc=mhocko@suse.com \
    --cc=npache@redhat.com \
    --cc=qi.zheng@linux.dev \
    --cc=rafael@kernel.org \
    --cc=rppt@kernel.org \
    --cc=ryan.roberts@arm.com \
    --cc=shakeel.butt@linux.dev \
    --cc=surenb@google.com \
    --cc=usama.arif@linux.dev \
    --cc=vbabka@kernel.org \
    --cc=weixugc@google.com \
    --cc=yuanchu@google.com \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.