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 <[email protected]> >>> To: Andrew Morton <[email protected]> >>> To: Baoquan He <[email protected]> >>> To: Mike Rapoport <[email protected]> >>> To: Pasha Tatashin <[email protected]> >>> To: Pratyush Yadav <[email protected]> >>> To: Jonathan Corbet <[email protected]> >>> To: "Matthew Wilcox (Oracle)" <[email protected]> >>> To: Jan Kara <[email protected]> >>> To: David Hildenbrand <[email protected]> >>> To: Steven Rostedt <[email protected]> >>> To: Masami Hiramatsu <[email protected]> >>> Cc: Dave Young <[email protected]> >>> Cc: Shuah Khan <[email protected]> >>> Cc: Lorenzo Stoakes <[email protected]> >>> Cc: "Liam R. Howlett" <[email protected]> >>> Cc: Vlastimil Babka <[email protected]> >>> Cc: Suren Baghdasaryan <[email protected]> >>> Cc: Michal Hocko <[email protected]> >>> Cc: Mathieu Desnoyers <[email protected]> >>> Cc: [email protected] >>> Cc: [email protected] >>> Cc: [email protected] >>> Cc: [email protected] >>> Cc: [email protected] >>> Cc: [email protected] >>> --- >>> 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? -- Cheers, David
