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