From: "Vishal Moola (Oracle)" <vishal.moola@gmail.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: Lance Yang <ioworker0@gmail.com>,
Huacai Chen <chenhuacai@loongson.cn>,
Andrew Morton <akpm@linux-foundation.org>,
Huacai Chen <chenhuacai@kernel.org>, Jan Kara <jack@suse.cz>,
Kevin Brodsky <kevin.brodsky@arm.com>,
Linux-Arch <linux-arch@vger.kernel.org>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
david@kernel.org, Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Lance Yang <lance.yang@linux.dev>
Subject: Re: [PATCH Resend] mm: Refine __{pgd,p4d,pud,pmd,pte}_alloc_one_*() about HIGHMEM
Date: Fri, 7 Nov 2025 08:34:29 -0800 [thread overview]
Message-ID: <aQ4flRonlCygowKA@fedora> (raw)
In-Reply-To: <f0efca40-aa3b-41ba-a8e4-c9595c19778e@app.fastmail.com>
On Fri, Nov 07, 2025 at 01:50:06PM +0100, Arnd Bergmann wrote:
> On Fri, Nov 7, 2025, at 12:44, Lance Yang wrote:
> > From: Lance Yang <lance.yang@linux.dev>
> > On Fri, 7 Nov 2025 17:59:22 +0800, Huacai Chen wrote:
> >>
> >> */
> >> static inline pte_t *__pte_alloc_one_kernel_noprof(struct mm_struct *mm)
> >> {
> >> - struct ptdesc *ptdesc = pagetable_alloc_noprof(GFP_PGTABLE_KERNEL &
> >> - ~__GFP_HIGHMEM, 0);
> >> + struct ptdesc *ptdesc = pagetable_alloc_noprof(GFP_PGTABLE_KERNEL, 0);
> >
> > I looked into the history and it seems you are right. This defensive pattern
> > was likely introduced by Vishal Moola in commit c787ae5[1].
>
> Right, so not even so long ago, so we need to make sure we agree
> on a direction and don't send opposite patches in the name of
> cleanups.
I took a look, this patch is the direction we want to go :).
> > After this cleanup, would it make sense to add a BUILD_BUG_ON() somewhere
> > to check that __GFP_HIGHMEM is not present in GFP_PGTABLE_KERNEL and
> > GFP_PGTABLE_USER? This would prevent any future regression ;)
> >
> > Just a thought ...
In this case, I don't think the extra check is necessary. This is a
remnant of defensively converting callers to the ptdesc api from
get_free_pages() variants (which masks off GFP_HIGHMEM internally).
I doubt we'll ever be changing those macros to support highmem.
> I think we can go either way here, but I'd tend towards not
> adding more checks but instead removing any mention of __GFP_HIGHMEM
> that we can show is either pointless or can be avoided, with
> the goal of having only a small number of actual highmem
> allocations remaining in places we do care about (normal
> page cache, zram, possibly huge pages).
+1
I'm not familiar with which architectures use highmem or not, so
theres likely more cases like this patch that are remnants of the
ptdesc conversion.
git grep "pagetable_alloc.*GFP_HIGHMEM" shows at least 5 references
inline that can definitely be removed. I'll go ahead and clean those up,
but I'll leave the rest to people more familiar with the architectures.
next prev parent reply other threads:[~2025-11-07 16:34 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-07 9:59 Huacai Chen
2025-11-07 11:21 ` Arnd Bergmann
2025-11-07 16:51 ` Vishal Moola (Oracle)
2025-11-09 7:43 ` Mike Rapoport
2025-11-07 11:44 ` Lance Yang
2025-11-07 12:50 ` Arnd Bergmann
2025-11-07 14:17 ` Lance Yang
2025-11-07 16:34 ` Vishal Moola (Oracle) [this message]
2025-11-07 16:58 ` Vishal Moola (Oracle)
2025-11-08 8:34 ` Huacai Chen
2025-11-08 16:47 ` Andrew Morton
2025-11-09 7:44 ` Mike Rapoport
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=aQ4flRonlCygowKA@fedora \
--to=vishal.moola@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=chenhuacai@kernel.org \
--cc=chenhuacai@loongson.cn \
--cc=david@kernel.org \
--cc=ioworker0@gmail.com \
--cc=jack@suse.cz \
--cc=kevin.brodsky@arm.com \
--cc=lance.yang@linux.dev \
--cc=linux-arch@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.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