On Tue, May 13, 2025 at 12:19 AM Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > > On Tue, 13 May 2025 at 00:59, Joanne Koong <joannelkoong@xxxxxxxxx> wrote: > > > > Optimize processing folios larger than one page size for the direct io > > case. If contiguous pages are part of the same folio, collate the > > processing instead of processing each page in the folio separately. > > This patch is sort of special in the series, since the others are > basically no-op until large folios are enabled. > > Did you validate this in particular? Is there a good way to test > direct I/O on a buffer with mixed folio sizes? Hi Miklos, No, I did not validate this case in particular. I'm happy to drop this patch for now and resend it when large folios get turned on, if you prefer that. It seems like it'd be good to add this case to xfstests. Matthew mentioned in [1] that this can get triggered by: "Userspace may mmap() a file PROT_WRITE, MAP_PRIVATE. If they store to the middle of a large folio (the file that is mmaped may be on a filesystem that does support large folios, rather than fuse), then we'll have, eg: folio A page 0 folio A page 1 folio B page 0 folio A page 3 where folio A belongs to the file and folio B is an anonymous COW page." Looking at iov_iter_extract_pages() more closely though, I'm realizing now that this function extracts only a list of *contiguous* pages, so I don't think we even run into a case where the extracted pages that get returned can have interleaved pages from another folio. Ideally though, the long-term solution would be having a iov_iter_extract_folios() API instead of having to use iov_iter_extract_pages() as a workaround. I'm hoping to take a stab at implementing that after the large folios work is done. Thanks, Joanne [1] https://lore.kernel.org/linux-fsdevel/Z1cSy1OUxPZ2kzYT@xxxxxxxxxxxxxxxxxxxx/ > > Thanks, > Miklos >
