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

[Vlastimil Babka (SUSE)]

On 7/20/26 19:52, Matthew Wilcox wrote:
> On Thu, Jul 16, 2026 at 04:57:37PM +0000, Brendan Jackman wrote:
>> On Thu Jul 16, 2026 at 4:48 PM UTC, Matthew Wilcox wrote:
>> > On Thu, Jul 16, 2026 at 02:30:10PM +0000, Brendan Jackman wrote:
>> >> 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.

>> 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.

>> ... 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.

>> 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.