>> Thanks for the pointer. I made a rough version of how it might
>> look like if I use that API:
>
> useful thing to do. i think this shows we need a new folio api wrapping
> it. happy to do that when i'm back, or you can have a crack at it.
>
A folio wrapping for mm_get_huge_zero_page()?
I tried to look for all the callers of mm_get_huge_zero_page() and I don't
see them doing the folio <-> page dance. Of course, if we end up using
mm_get_huge_zero_page() in iomap, then getting making a folio API might be
worth it!
> your point about it possibly failing is correct. so i think we need an
> api which definitely returns a folio, but it might be of arbitrary
> order.
>
That will be really nice, given that many parts of the kernel might
use that API to get away with iterating with ZERO_PAGE().
>> +
>> iomap_dio_submit_bio(iter, dio, bio, pos);
>
> then this can look something like:
>
> while (len) {
> size_t size = min(len, folio_size(folio));
>
> __bio_add_folio(bio, folio, size, 0);
> len -= size;
> }
>
Ah, this looks good!
>> PS: Enjoy your holidays :)
>
> cheers ;-)
