Re: [PATCH v12 01/16] set_memory: set_direct_map_* to take address

[Brendan Jackman]

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 <nikita.kalyazin@xxxxxxxxx>
>>>>
>>>> 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/DJJ2NKKPRANG.188CUADJO2CKK@xxxxxxxxx/

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