All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Brendan Jackman <jackmanb@google.com>,
	Gregory Price <gourry@gourry.net>,
	linux-mm@kvack.org
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,
	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: Mon, 18 May 2026 11:59:39 +0200	[thread overview]
Message-ID: <16ca5667-ae65-4bf0-8efb-e51bf7d70c87@kernel.org> (raw)
In-Reply-To: <DIJ5IBGSO0OC.1S6AARO01CD6T@google.com>

On 5/15/26 11:43, Brendan Jackman wrote:
> 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 ...
>>     };

Wouldn't it be cleaner to really only export what we want external users to
consume? IOW, a split between internal and external flags. We do that for
gup-flags, but I wouldn't suggest that models as is, just the overall idea.
There are other ways to achieve it I guess.

-- 
Cheers,

David


  parent reply	other threads:[~2026-05-18 10:00 UTC|newest]

Thread overview: 7+ 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
2026-05-15 15:48   ` Gregory Price
2026-05-15 17:09     ` Brendan Jackman
2026-05-17 14:05       ` Gregory Price
2026-05-18  9:59   ` David Hildenbrand (Arm) [this message]
2026-05-18  7:12 ` Harry Yoo (Oracle)

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=16ca5667-ae65-4bf0-8efb-e51bf7d70c87@kernel.org \
    --to=david@kernel.org \
    --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=dev.jain@arm.com \
    --cc=gourry@gourry.net \
    --cc=hannes@cmpxchg.org \
    --cc=harry.yoo@oracle.com \
    --cc=ira.weiny@intel.com \
    --cc=jackmanb@google.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.