On 07.12.23 14:05, Jason Gunthorpe wrote:
On Thu, Dec 07, 2023 at 10:44:14AM +0100, David Hildenbrand wrote:
If you always want to return folios, then better name it
"memfd_pin_user_folios" (or just "memfd_pin_folios") and pass in a range
(instead of a nr_pages parameter), and somehow indicate to the caller
how many folio were in that range, and if that range was fully covered.
I think it makes sense to return folios from this interface; and considering my
use-case, I'd like have this API return an error if it cannot pin (or allocate)
the exact number of folios the caller requested.
Okay, then better use folios.
Assuming a caller puts in "start = X" and gets some large folio back. How is
the caller supposed to know at which offset to look into that folio (IOW<
which subpage)? For "pages" it was obvious (you get the actual subpages),
but as soon as we return a large folio, some information is missing for the
caller.
How can the caller figure that out?
This can only work if the memfd is required to only have full folios
at aligned locations. Under that restriction computing the first folio
offset is easy enough:
folio offset = (start % folio size)
But is that true for the memfds here?
I assume folios are always naturally aligned, like:
[ 2m ][ 2m ][1m][1m][ 2m ]
^f0 ^f1 ^f2 ^f3 ^f4
If you query the range "3m -> 7m", you get back f1,f2,f3,f4 and have to
start in the middle of the first folio with offset 1m. From there, it is
indeed simply continuing with the full folio size -- until the last
folio, where you want to only process 1m.
folio offset = (1m % 2m)
would be correct in that case.
--
Cheers,
David / dhildenb
