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.