Re: [PATCH v3 14/14] mm/page-flags: remove PG_private

[Zi Yan <ziy@nvidia.com>]

On 9 Sep 2026, at 10:50, David Hildenbrand (Arm) wrote:

> On 9/9/26 16:48, Zi Yan wrote:
>> On 9 Sep 2026, at 10:31, David Hildenbrand (Arm) wrote:
>>
>>> 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.
>>
>> Yeah, I will fold the document changes into the corresponding code change patches.
>>
>>>
>>>>  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)
>>
>> No one complained about this yet. :)
>>
>> I do this because I do not want to change PG_* values after PG_private after
>> PG_private is removed. And they will be changed back to their original values
>> when I add PG_folio. That PG_* value churn might be a headache for kdump?
>> If I add PG_folio the last page flag, it can be a one-time change though.
>
> Sorry, I meant that you just use
>
> PG_folio,		/* Do not use: reserved for folio identification */
>
> Without any further churn. Or is there a problem with this?

Probably not. Let me do that.

Best Regards,
Yan, Zi