Re: [PATCH 1/3] mm: move internal mempolicy APIs to new internal header

On 7/20/26 19:52, Matthew Wilcox wrote:

On Thu, Jul 16, 2026 at 04:57:37PM +0000, Brendan Jackman wrote:

quoted

On Thu Jul 16, 2026 at 4:48 PM UTC, Matthew Wilcox wrote:

quoted

On Thu, Jul 16, 2026 at 02:30:10PM +0000, Brendan Jackman wrote:

quoted

There are no external users for this surface, reduce the scope.
-struct folio *folio_alloc_mpol_noprof(gfp_t gfp, unsigned int order,
-		struct mempolicy *mpol, pgoff_t ilx, int nid);

Hm.  So what we're saying is that allocations which respect mempolicy are
only for core mm and not for, eg, device drivers to do.  Is that really
what we want to say?  I don't think so, because that's inconsistent
with having just widened __filemap_get_folio_mpol to allow guest_memfd
to specify a mempolicy.

guest_memfd is practically mm internal though, IMHO.

quoted

Yeah I agree, mempolicy definitely seems like a "public concept".  All
I'm saying here is this specific function doesn't have any external
users so it doesn't need to be an external header. 

I don't think that should be the metric for moving things to internal.h.
To me, internal.h is a signifier that these interfaces should only be
used by the MM.  Not that "all current users are within the MM".

Perhaps. It can be also useful to move them outside only when someone asks.

quoted

... With the ulterior motive that I want to add a new parameter to it
that actually _is_ mm-internal. Namely, alloc_flags, so I can add
ALLOC_UNMAPPED to implement AS_NO_DIRECT_MAP, i.e. the next iteration of
[0]. So basically this is
about trying to extend the allocator without creating a GFP flag.

Yeah.  I'm not sold on the whole alloc_flags thing, but I'm too busy to
sit down and think it through properly to get involved in a proper
argument about how it should work.

Well it's basically a workaround for limited gfp flags space. So we can
extend it without making that a cost for everybody, as long as those that
need the new functionality are limited.

My entirely unresearched and ill-considered opinion is that the __GFP
flags should _be_ the ALLOC flags.  We shoudn't be translating GFP flags
into ALLOC flags that are what the allocator actually uses, the

It uses both.

translation should be done at compile time.  So if GFP_KERNEL and

That would assume the gfp flags are also known at compile time, which is not
always the case.

GFP_ATOMIC need to be composed of different flags with different

The flags we are adding/considering to add are not about GFP_KERNEL vs
GFP_ATOMIC context, however.

semantics, then we should do that, not invent a different set of flags
that special people can use for special purposes.

Yep it's ugly and pragmatic, as usual. At least it's not immortalized as an
UAPI, so we can deal with exploring in a wrong direction and fixing it later.

quoted

So I'm envisaging if an external user arises for it later, we'd slap two
underscores on the beginning of the internal one, (with the alloc_flags
arg), and then bring back the public one as a wrapper.

Does that make sense?

We have a long history of people just moving stuff around in patches
without knowing what the intent was if it should be moved.

I guess this patch is not critical to the rest, if that's an issue.