From: Brendan Jackman <jackmanb@google.com>
To: Gregory Price <gourry@gourry.net>, <linux-mm@kvack.org>,
<jackmanb@google.com>
Cc: <kernel-team@meta.com>, <vishal.l.verma@intel.com>,
<ira.weiny@intel.com>, <dan.j.williams@intel.com>,
<longman@redhat.com>, <akpm@linux-foundation.org>,
<david@kernel.org>, <lorenzo.stoakes@oracle.com>,
<Liam.Howlett@oracle.com>, <vbabka@suse.cz>, <rppt@kernel.org>,
<surenb@google.com>, <mhocko@suse.com>, <osalvador@suse.de>,
<ziy@nvidia.com>, <matthew.brost@intel.com>,
<joshua.hahnjy@gmail.com>, <rakie.kim@sk.com>,
<byungchul@sk.com>, <ying.huang@linux.alibaba.com>,
<apopple@nvidia.com>, <axelrasmussen@google.com>,
<yuanchu@google.com>, <weixugc@google.com>,
<yury.norov@gmail.com>, <linux@rasmusvillemoes.dk>,
<mhiramat@kernel.org>, <mathieu.desnoyers@efficios.com>,
<tj@kernel.org>, <hannes@cmpxchg.org>, <mkoutny@suse.com>,
<sj@kernel.org>, <baolin.wang@linux.alibaba.com>,
<npache@redhat.com>, <ryan.roberts@arm.com>, <dev.jain@arm.com>,
<baohua@kernel.org>, <lance.yang@linux.dev>,
<muchun.song@linux.dev>, <xu.xin16@zte.com.cn>,
<chengming.zhou@linux.dev>, <jannh@google.com>,
<linmiaohe@huawei.com>, <nao.horiguchi@gmail.com>,
<pfalcato@suse.de>, <rientjes@google.com>,
<shakeel.butt@linux.dev>, <riel@surriel.com>,
<harry.yoo@oracle.com>, <cl@gentwo.org>,
<roman.gushchin@linux.dev>, <chrisl@kernel.org>,
<kasong@tencent.com>, <shikemeng@huaweicloud.com>,
<nphamcs@gmail.com>, <bhe@redhat.com>,
<zhengqi.arch@bytedance.com>, <terry.bowman@amd.com>,
<owner-linux-mm@kvack.org>
Subject: Re: [RFC] __GFP_UNMAPPED and __GFP_PRIVATE follow up
Date: Fri, 15 May 2026 09:43:02 +0000 [thread overview]
Message-ID: <DIJ5IBGSO0OC.1S6AARO01CD6T@google.com> (raw)
In-Reply-To: <agYJcRgOHho8upVv@gourry-fedora-PF4VCD3F>
On Thu May 14, 2026 at 5:42 PM UTC, Gregory Price wrote:
...
> Maybe we could modify alloc_flags to be a struct, and export that
> without being tied to down to a 32/64-bit flag field - and mark certain
> sets of alloc flags verboten (internally controlled / controlled by GFP
> flags, and will either be ignored or cause a BUG()).
>
> Then we could get something like:
>
> struct alloc_flags {
> /*
> * internal only: will be ignored, cleared, or cause BUG() if used,
> * or should be applied via the appropriate __GFP flag.
> */
> uint64_t wmark_min : 1;
> uint64_t wmark_low : 1;
> uint64_t wmark_high : 1;
> ... etc ...
> /*
> * external context flags
> * allows explicit access to certain resources
> */
> uint64_t cma : 1; /* allows access to CMA regions */
> uint64_t unmapped : 1; /* return pages in unmapped state */
> uint64_t managed_node : 1; /* allows access to managed node */
> ... etc ...
> };
>
> ___alloc_frozen_pages_noprof(..., struct alloc_context *ac) {
> ac->flags.wmark_low = 1;
> ...
> prepare_alloc_pages(..., ac);
> ac->flags.nofrag = alloc_flags_nofragment(...)
>
> /* First allocation attempt */
> page = get_page_from_freelist(alloc_gfp, order, &ac);
> ...
> }
>
> __alloc_frozen_pages_noprof(...) {
> struct alloc_context ac = {};
>
> ___alloc_frozen_pages_noprof(..., ac);
> }
>
> __alloc_frozen_pages_context_noprof(..., struct alloc_flags *aflags) {
> struct alloc_context ac = {};
>
> /* Snapshot to prevent external changes */
> ac.flags = aflags ? *aflags : 0;
>
> sanitize_alloc_flags(&ac.flags); /* BUG() on insanity */
> ___alloc_frozen_pages_noprof(..., ac);
> }
Yeah, I have had a similar thought before. In fact, I wonder if we could
have a pointer in there that effectively allows you to replace
NODE_DATA? I think that would be a more general mechanism to achieve
that `managed_node` thing?
My original motive for that was: if we could get the allocator to stop
[unconditionally] mutating global variables it would make it easier to
test.
My feeling from poking around in the code is that setting this up is
actually quite a big job in page_alloc.c. But, I think it could be done
in a way that leaves the code better instead of worse.
There might be some annoying stuff like "turning these things that are
currently function arguments into struct fields effectively causes a
register spill and this code is hot enough for that to matter"? But that
seems like a bridge to cross if we come to it, not something to
premature-optimise over. (Do register spills matter in 2026 anyway?
I think registers and the stack are kinda virtual?)
(Sorry this is such a vague thumbs up without really contributing
anything but I'm just giving what I've got :D)
next prev parent reply other threads:[~2026-05-15 9:43 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-14 17:42 [RFC] __GFP_UNMAPPED and __GFP_PRIVATE follow up Gregory Price
2026-05-15 9:43 ` Brendan Jackman [this message]
2026-05-15 15:48 ` Gregory Price
2026-05-15 17:09 ` Brendan Jackman
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=DIJ5IBGSO0OC.1S6AARO01CD6T@google.com \
--to=jackmanb@google.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=bhe@redhat.com \
--cc=byungchul@sk.com \
--cc=chengming.zhou@linux.dev \
--cc=chrisl@kernel.org \
--cc=cl@gentwo.org \
--cc=dan.j.williams@intel.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=harry.yoo@oracle.com \
--cc=ira.weiny@intel.com \
--cc=jannh@google.com \
--cc=joshua.hahnjy@gmail.com \
--cc=kasong@tencent.com \
--cc=kernel-team@meta.com \
--cc=lance.yang@linux.dev \
--cc=linmiaohe@huawei.com \
--cc=linux-mm@kvack.org \
--cc=linux@rasmusvillemoes.dk \
--cc=longman@redhat.com \
--cc=lorenzo.stoakes@oracle.com \
--cc=mathieu.desnoyers@efficios.com \
--cc=matthew.brost@intel.com \
--cc=mhiramat@kernel.org \
--cc=mhocko@suse.com \
--cc=mkoutny@suse.com \
--cc=muchun.song@linux.dev \
--cc=nao.horiguchi@gmail.com \
--cc=npache@redhat.com \
--cc=nphamcs@gmail.com \
--cc=osalvador@suse.de \
--cc=owner-linux-mm@kvack.org \
--cc=pfalcato@suse.de \
--cc=rakie.kim@sk.com \
--cc=riel@surriel.com \
--cc=rientjes@google.com \
--cc=roman.gushchin@linux.dev \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=shakeel.butt@linux.dev \
--cc=shikemeng@huaweicloud.com \
--cc=sj@kernel.org \
--cc=surenb@google.com \
--cc=terry.bowman@amd.com \
--cc=tj@kernel.org \
--cc=vbabka@suse.cz \
--cc=vishal.l.verma@intel.com \
--cc=weixugc@google.com \
--cc=xu.xin16@zte.com.cn \
--cc=ying.huang@linux.alibaba.com \
--cc=yuanchu@google.com \
--cc=yury.norov@gmail.com \
--cc=zhengqi.arch@bytedance.com \
--cc=ziy@nvidia.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.