From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Zi Yan <ziy@nvidia.com>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Muchun Song <muchun.song@linux.dev>,
Lorenzo Stoakes <ljs@kernel.org>,
"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>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Nico Pache <nico.pache@linux.dev>,
Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
Barry Song <baohua@kernel.org>, Lance Yang <lance.yang@linux.dev>,
Usama Arif <usama.arif@linux.dev>,
Gregory Price <gourry@gourry.net>,
Ying Huang <ying.huang@linux.alibaba.com>,
Alistair Popple <apopple@nvidia.com>,
Johannes Weiner <hannes@cmpxchg.org>,
Qi Zheng <qi.zheng@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Kairui Song <kasong@tencent.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Baoquan He <baoquan.he@linux.dev>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Pratyush Yadav <pratyush@kernel.org>,
Jonathan Corbet <corbet@lwn.net>, Jan Kara <jack@suse.cz>,
Steven Rostedt <rostedt@goodmis.org>,
Masami Hiramatsu <mhiramat@kernel.org>,
Dave Young <ruirui.yang@linux.dev>,
Shuah Khan <skhan@linuxfoundation.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
kexec@lists.infradead.org, linux-doc@vger.kernel.org,
linux-fsdevel@vger.kernel.org,
linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH v3 14/14] mm/page-flags: remove PG_private
Date: Wed, 9 Sep 2026 16:31:49 +0200 [thread overview]
Message-ID: <d8e9b629-4198-4281-a3b2-d54445201fd2@kernel.org> (raw)
In-Reply-To: <20260907-remove-pg_private-v3-14-6ae22f9d9272@nvidia.com>
On 9/8/26 04:56, Zi Yan wrote:
> folio->private != NULL indicates a folio carries private data, replacing
> PG_private. All PG_private users are converted. Remove PG_private and
> reserve the space as __PG_folio for future use.
>
> __DEF_PAGEFLAG_NAME() is added to show __PG_folio.
>
> Also update files in Documentation. hugetlbfs_reserv.rst is outdated and
> left unchanged. It should be rewritten.
>
> Assisted-by: Claude:claude-opus-4-8
> Assisted-by: Codex:gpt-5
> Signed-off-by: Zi Yan <ziy@nvidia.com>
> To: Andrew Morton <akpm@linux-foundation.org>
> To: Baoquan He <baoquan.he@linux.dev>
> To: Mike Rapoport <rppt@kernel.org>
> To: Pasha Tatashin <pasha.tatashin@soleen.com>
> To: Pratyush Yadav <pratyush@kernel.org>
> To: Jonathan Corbet <corbet@lwn.net>
> To: "Matthew Wilcox (Oracle)" <willy@infradead.org>
> To: Jan Kara <jack@suse.cz>
> To: David Hildenbrand <david@kernel.org>
> To: Steven Rostedt <rostedt@goodmis.org>
> To: Masami Hiramatsu <mhiramat@kernel.org>
> Cc: Dave Young <ruirui.yang@linux.dev>
> Cc: Shuah Khan <skhan@linuxfoundation.org>
> Cc: Lorenzo Stoakes <ljs@kernel.org>
> Cc: "Liam R. Howlett" <liam@infradead.org>
> Cc: Vlastimil Babka <vbabka@kernel.org>
> Cc: Suren Baghdasaryan <surenb@google.com>
> Cc: Michal Hocko <mhocko@suse.com>
> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
> Cc: kexec@lists.infradead.org
> Cc: linux-doc@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-fsdevel@vger.kernel.org
> Cc: linux-mm@kvack.org
> Cc: linux-trace-kernel@vger.kernel.org
> ---
> Documentation/admin-guide/kdump/vmcoreinfo.rst | 2 +-
> Documentation/filesystems/vfs.rst | 6 +++---
> include/linux/page-flags.h | 19 ++-----------------
> include/trace/events/mmflags.h | 3 ++-
> kernel/vmcore_info.c | 1 -
> 5 files changed, 8 insertions(+), 23 deletions(-)
>
> diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst
> index 7663c610fe901..5f1df6d080508 100644
> --- a/Documentation/admin-guide/kdump/vmcoreinfo.rst
> +++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst
> @@ -325,7 +325,7 @@ NR_FREE_PAGES
> On linux-2.6.21 or later, the number of free pages is in
> vm_stat[NR_FREE_PAGES]. Used to get the number of free pages.
>
> -PG_lru|PG_private|PG_swapcache|PG_swapbacked|PG_hwpoison|PG_head_mask
> +PG_lru|PG_swapcache|PG_swapbacked|PG_hwpoison|PG_head_mask
> --------------------------------------------------------------------------
>
> Page attributes. These flags are used to filter various unnecessary for
> diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst
> index d3a93eec3945f..dec7816303c6a 100644
> --- a/Documentation/filesystems/vfs.rst
> +++ b/Documentation/filesystems/vfs.rst
> @@ -649,8 +649,8 @@ Writeback.
>
> The first can be used independently to the others. The VM can try to
> release clean pages in order to reuse them. To do this it can call
> -->release_folio on clean folios with the private
> -flag set. Clean pages without PagePrivate and with no external references
> +->release_folio on clean folios with folio->private set. Clean pages
> +without folio->private set and with no external references
> will be released without notice being given to the address_space.
This reads like it would belong into patch #13?
>
> To achieve this functionality, pages need to be placed on an LRU with
> @@ -674,7 +674,7 @@ filemap_fdatawait_range, to wait for all writeback to complete.
>
> An address_space handler may attach extra information to a page,
> typically using the 'private' field in the 'struct page'. If such
> -information is attached, the PG_Private flag should be set. This will
> +information is attached, non-NULL 'private' field will
Same here?
Likely this could have been restructured to cause less head scratches. I'd
expect any documentation that refers to PG_private to get removed before finally
removing the bit.
Not the end of the world, just a bit confusing while reviewing.
> cause various VM routines to make extra calls into the address_space
> handler to deal with that data.
>
> diff --git a/include/linux/page-flags.h b/include/linux/page-flags.h
> index ce7fccd90367b..7b7783c0a5216 100644
> --- a/include/linux/page-flags.h
> +++ b/include/linux/page-flags.h
> @@ -44,10 +44,6 @@
> * Consequently, PG_reserved for a page mapped into user space can indicate
> * the zero page, the vDSO, MMIO pages or device memory.
> *
> - * The PG_private bitflag is set on pagecache pages if they contain filesystem
> - * specific data (which is normally at page->private). It can be used by
> - * private allocations for its own usage.
> - *
> * During initiation of disk I/O, PG_locked is set. This bit is set before I/O
> * and cleared when writeback _starts_ or when read _completes_. PG_writeback
> * is set before writeback starts and cleared when it finishes.
> @@ -105,7 +101,7 @@ enum pageflags {
> PG_owner_2, /* Owner use. If pagecache, fs may use */
> PG_arch_1,
> PG_reserved,
> - PG_private, /* If pagecache, has fs-private data */
> + __PG_folio, /* Do not use: reserved for folio identification */
Do we really have to annotate it with __PG_folio ? I'd just keep it simple and
have the comment. That also avoids __DEF_PAGEFLAG_NAME just for this use case.
(sorry if this was discussed in previous review rounds)
--
Cheers,
David
next prev parent reply other threads:[~2026-09-09 14:32 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-08 2:56 [PATCH v3 00/14] Remove PG_private by using page/folio->private checks instead Zi Yan
2026-09-08 2:56 ` [PATCH v3 07/14] erofs: mm/pagemap: add readahead_folio_last() to avoid folio->private Zi Yan
2026-09-08 16:04 ` David Hildenbrand (Arm)
2026-09-08 17:05 ` Zi Yan
2026-09-09 14:10 ` David Hildenbrand (Arm)
2026-09-08 2:56 ` [PATCH v3 09/14] mm/page-flags: check page/folio->private instead of PG_private Zi Yan
2026-09-08 16:56 ` David Hildenbrand (Arm)
2026-09-10 2:08 ` Zi Yan
2026-09-08 2:56 ` [PATCH v3 10/14] mm/page-flags: introduce folio_test_fs_private() Zi Yan
2026-09-08 16:59 ` David Hildenbrand (Arm)
2026-09-08 17:22 ` Zi Yan
2026-09-08 2:56 ` [PATCH v3 11/14] treewide: remove folio_set/clear_private() Zi Yan
2026-09-08 17:01 ` David Hildenbrand (Arm)
2026-09-08 17:22 ` Zi Yan
2026-09-08 2:56 ` [PATCH v3 14/14] mm/page-flags: remove PG_private Zi Yan
2026-09-09 14:31 ` David Hildenbrand (Arm) [this message]
2026-09-09 14:48 ` Zi Yan
2026-09-09 14:50 ` David Hildenbrand (Arm)
2026-09-09 14:51 ` Zi Yan
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=d8e9b629-4198-4281-a3b2-d54445201fd2@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=baoquan.he@linux.dev \
--cc=corbet@lwn.net \
--cc=dev.jain@arm.com \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=jack@suse.cz \
--cc=kasong@tencent.com \
--cc=kexec@lists.infradead.org \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=mhiramat@kernel.org \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=nico.pache@linux.dev \
--cc=pasha.tatashin@soleen.com \
--cc=pratyush@kernel.org \
--cc=qi.zheng@linux.dev \
--cc=rostedt@goodmis.org \
--cc=rppt@kernel.org \
--cc=ruirui.yang@linux.dev \
--cc=ryan.roberts@arm.com \
--cc=shakeel.butt@linux.dev \
--cc=skhan@linuxfoundation.org \
--cc=surenb@google.com \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--cc=willy@infradead.org \
--cc=ying.huang@linux.alibaba.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox