From: Andrew Morton <akpm@linux-foundation.org>
To: Stephen Brennan <stephen.s.brennan@oracle.com>
Cc: linux-mm@kvack.org, Vlastimil Babka <vbabka@suse.cz>,
"Vishal Moola (Oracle)" <vishal.moola@gmail.com>,
Omar Sandoval <osandov@osandov.com>,
David Hildenbrand <david@redhat.com>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Hao Ge <gehao@kylinos.cn>,
linux-debuggers@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v4] mm: convert page type macros to enum
Date: Mon, 17 Jun 2024 14:29:51 -0700 [thread overview]
Message-ID: <20240617142951.08a9cdc791c8edeeca50509b@linux-foundation.org> (raw)
In-Reply-To: <87bk3z1f76.fsf@oracle.com>
On Mon, 17 Jun 2024 13:34:21 -0700 Stephen Brennan <stephen.s.brennan@oracle.com> wrote:
> >>> Fixes: 46df8e73a4a3 ("mm: free up PG_slab")
> >>
> >> Should we backport this into 6.9.x?
> >
> > Hi Andrew,
> >
> > Looks like commit 46df8e73a4a3 ("mm: free up PG_slab") is introduced in
> > the v6.10-rc's, and not backported to 6.9. So PG_slab is still part of
>
> Hi Andrew,
>
> I saw that you've merged this into mm-unstable, thank you!
>
> Since 46df8e73a4a3 ("mm: free up PG_slab") is part of the current 6.10
> RC, it would be great if this patch could be part of the 6.10 release so
> we don't release a kernel missing the PG_slab info.
>
> Can you confirm if mm-unstable will get merged in this release cycle? Or
> else, would it be possible to include it in a branch that will?
Turns out the patch as sent was based on David's "mm: allow reuse of
the lower 16 bit of the page type with an actual type", which changed
the page flags a lot, I redid this patch thusly:
--- a/include/linux/page-flags.h~mm-convert-page-type-macros-to-enum
+++ a/include/linux/page-flags.h
@@ -944,15 +944,22 @@ PAGEFLAG_FALSE(HasHWPoisoned, has_hwpois
* mistaken for a page type value.
*/
-#define PAGE_TYPE_BASE 0xf0000000
-/* Reserve 0x0000007f to catch underflows of _mapcount */
-#define PAGE_MAPCOUNT_RESERVE -128
-#define PG_buddy 0x00000080
-#define PG_offline 0x00000100
-#define PG_table 0x00000200
-#define PG_guard 0x00000400
-#define PG_hugetlb 0x00000800
-#define PG_slab 0x00001000
+enum pagetype {
+ /*
+ * Reserve 0xffff0000 - 0xfffffffe to catch _mapcount underflows and
+ * allow owners that set a type to reuse the lower 16 bit for their own
+ * purposes.
+ */
+ PG_buddy = 0x00000080,
+ PG_offline = 0x00000100,
+ PG_table = 0x00000200,
+ PG_guard = 0x00000400,
+ PG_hugetlb = 0x00000800,
+ PG_slab = 0x00001000,
+
+ PAGE_TYPE_BASE = 0xf0000000,
+ PAGE_MAPCOUNT_RESERVE = -128,
+};
#define PageType(page, flag) \
((page->page_type & (PAGE_TYPE_BASE | flag)) == PAGE_TYPE_BASE)
_
(please check carefully)
and David's later "mm: allow reuse of the lower 16 bit of the page type
with an actual type" becomes
include/linux/mm_types.h | 5 +++++
include/linux/page-flags.h | 16 ++++++++--------
2 files changed, 13 insertions(+), 8 deletions(-)
--- a/include/linux/mm_types.h~mm-allow-reuse-of-the-lower-16-bit-of-the-page-type-with-an-actual-type
+++ a/include/linux/mm_types.h
@@ -157,6 +157,11 @@ struct page {
*
* See page-flags.h for a list of page types which are currently
* stored here.
+ *
+ * Owners of typed folios may reuse the lower 16 bit of the
+ * head page page_type field after setting the page type,
+ * but must reset these 16 bit to -1 before clearing the
+ * page type.
*/
unsigned int page_type;
--- a/include/linux/page-flags.h~mm-allow-reuse-of-the-lower-16-bit-of-the-page-type-with-an-actual-type
+++ a/include/linux/page-flags.h
@@ -951,15 +951,15 @@ enum pagetype {
* allow owners that set a type to reuse the lower 16 bit for their own
* purposes.
*/
- PG_buddy = 0x00000080,
- PG_offline = 0x00000100,
- PG_table = 0x00000200,
- PG_guard = 0x00000400,
- PG_hugetlb = 0x00000800,
- PG_slab = 0x00001000,
+ PG_buddy = 0x40000000,
+ PG_offline = 0x20000000,
+ PG_table = 0x10000000,
+ PG_guard = 0x08000000,
+ PG_hugetlb = 0x04008000,
+ PG_slab = 0x02000000,
- PAGE_TYPE_BASE = 0xf0000000,
- PAGE_MAPCOUNT_RESERVE = -128,
+ PAGE_TYPE_BASE = 0x80000000,
+ PAGE_MAPCOUNT_RESERVE = (~0x0000ffff),
};
#define PageType(page, flag) \
_
and that patch's fixup becomes
--- a/include/linux/page-flags.h~mm-allow-reuse-of-the-lower-16-bit-of-the-page-type-with-an-actual-type-fix
+++ a/include/linux/page-flags.h
@@ -955,7 +955,7 @@ enum pagetype {
PG_offline = 0x20000000,
PG_table = 0x10000000,
PG_guard = 0x08000000,
- PG_hugetlb = 0x04008000,
+ PG_hugetlb = 0x04000000,
PG_slab = 0x02000000,
PAGE_TYPE_BASE = 0x80000000,
_
and "mm/zsmalloc: use a proper page type" becomes, in part,
--- a/include/linux/page-flags.h~mm-zsmalloc-use-a-proper-page-type
+++ a/include/linux/page-flags.h
@@ -957,6 +957,7 @@ enum pagetype {
PG_guard = 0x08000000,
PG_hugetlb = 0x04000000,
PG_slab = 0x02000000,
+ PG_zsmalloc = 0x01000000,
PAGE_TYPE_BASE = 0x80000000,
PAGE_MAPCOUNT_RESERVE = (~0x0000ffff),
and the end result is identical to yesterday's mm-everything so that's
all good.
However I wouldn't want to send the altered version of "mm: convert
page type macros to enum" into 6.10-rcX because it gets so altered by
David's mm-unstable changes for the next merge window. The new version
of the hotfixes patch won't have had any valid testing on its own.
So I'll temporarily drop David's "mm: page_type, zsmalloc and
page_mapcount_reset()" series from mm-unstable. To permit the new "mm:
convert page type macros to enum" to get some linux-next exposure.
David, please remind me to restore that series in a week or so?
next prev parent reply other threads:[~2024-06-17 21:29 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-07 20:29 Stephen Brennan
2024-06-08 4:27 ` Andrew Morton
2024-06-10 22:41 ` Stephen Brennan
2024-06-17 20:34 ` Stephen Brennan
2024-06-17 20:59 ` Andrew Morton
2024-06-17 21:29 ` Andrew Morton [this message]
2024-06-17 22:14 ` Stephen Brennan
2024-06-18 21:14 ` Andrew Morton
2024-06-18 6:35 ` David Hildenbrand
2024-06-11 13:07 ` Vlastimil Babka
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=20240617142951.08a9cdc791c8edeeca50509b@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=david@redhat.com \
--cc=gehao@kylinos.cn \
--cc=linux-debuggers@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=osandov@osandov.com \
--cc=stephen.s.brennan@oracle.com \
--cc=vbabka@suse.cz \
--cc=vishal.moola@gmail.com \
--cc=willy@infradead.org \
/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