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

"Vlastimil Babka (SUSE)" <[email protected]> Wed, 29 Jul 2026 17:49:49 +0200
Newsgroups dev.linux.lists.loongarch,dev.linux.lists.iommu,org.kernel.vger.linux-fsdevel,org.kernel.vger.linux-kernel,org.kernel.vger.linux-nfs,org.kernel.vger.netdev,org.kvack.linux-mm
Message-ID <[email protected]>
On 7/29/26 13:50, Brendan Jackman wrote:
> On Wed Jul 22, 2026 at 3:15 PM UTC, Brendan Jackman wrote:
> ...
>>>> 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.
>>
>> Well, for ALLOC_UNMAPPED we really do need an alloc_flags arg for this
>> function, but we can always just go straight to what I described above.
>> I.e. I can create the __ variant + wrapper from the start. It's just a
>> question of whether we prefer:
>>
>> - "Yuck, there's a public wrapper here that we don't actually need", or
>>
>> - "We hid this mempolicy API and people might think we'd NACK a patch to
>>   un-hide it".0
>>
>>   https://lore.kernel.org/all/[email protected]/
> 
> Uh yeah so in v3 I did not depend on this patch, I just went straight to
> creating __folio_alloc_mpol_noprof() here:
> 
> https://lore.kernel.org/all/[email protected]/
> 
> So yeah I'd say we can just drop this controversial patch and move
> forwards with the other two?

Ack.