On Fri Jun 26, 2026 at 2:58 PM UTC, David Hildenbrand (Arm) wrote: > On 6/26/26 16:38, Brendan Jackman wrote: >> On Tue Apr 21, 2026 at 2:43 PM UTC, Lorenzo Stoakes wrote: >>> On Fri, Apr 10, 2026 at 03:17:58PM +0000, Kalyazin, Nikita wrote: >>>> From: Nikita Kalyazin <[email protected]> >>>> >>>> Let's convert set_direct_map_*() to take an address instead of a page to >>>> prepare for adding helpers that operate on folios; it will be more >>>> efficient to convert from a folio directly to an address without going >>>> through a page first. >> >> Why is this more efficient? Isn't it a purely compile-time conversion? >> >> Indeed in the current implementation folio_address() is >> page_address(&folio->page) so it still goes through a page anyway, no? >> >> I might be missing context here about how this will look in the >> memdesc future. > > Good question. page_address() is really only complicated for highmem. For > non-highmem stuff it's simply derived from the page pfn. > > I suspect going page -> pfn will remain as efficient as it currently is (with > vmemmap). For odd cases (SPARSEMEM without VMEMMAP) going through folio->pfn > [1] > might be slighty faster. > > [1] https://kernelnewbies.org/MatthewWilcox/Memdescs/Path
Ah sorry I raced with you and replied to myself: https://lore.kernel.org/all/[email protected]/ The above makes me realise that if we really do want to avoid needing a struct page here, the "right" thing would be to make this API accept a PFN. The problem would be that our favourite programming language we use doesn't know the difference between `unsigned long addr` and `unsigned long pfn`... but I thiiiiink its unlikely those bugs will be latent, I've made that mistake a few times and my computer usually let me know about it. Still, I'm not really convinced we need to change anything here yet (modulo fuzziness about memdesc etc).
