From: David Hildenbrand <david@redhat.com>
To: Andrew Morton <akpm@linux-foundation.org>,
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>,
"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: Tue, 18 Jun 2024 08:35:27 +0200 [thread overview]
Message-ID: <dc8467bf-4f27-4aac-b7a2-a0aaff6a3eaa@redhat.com> (raw)
In-Reply-To: <20240617142951.08a9cdc791c8edeeca50509b@linux-foundation.org>
On 17.06.24 23:29, Andrew Morton wrote:
> 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.
> + */
As noted, we better maintain the original comment here.
> + 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)
> _
>
Apart from that LGTM.
> (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.
Looks 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?
I'll be on vacation next week, but will try to think of it. If you want
a resend based on the new mm-unstable state with that hotfix, let me know.
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2024-06-18 6:35 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
2024-06-17 22:14 ` Stephen Brennan
2024-06-18 21:14 ` Andrew Morton
2024-06-18 6:35 ` David Hildenbrand [this message]
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=dc8467bf-4f27-4aac-b7a2-a0aaff6a3eaa@redhat.com \
--to=david@redhat.com \
--cc=akpm@linux-foundation.org \
--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