Re: [PATCH v2 6/7] nfs: Optimize direct I/O to use folios for requests
Christoph Hellwig <[email protected]>
| Newsgroups | gmane.linux.kernel,gmane.linux.nfs,gmane.linux.kernel.mm,gmane.linux.file-systems |
|---|---|
| Message-ID | <[email protected]> |
[sorry, dropped the ball a bit on this due to overload] On Thu, Jun 18, 2026 at 07:20:06PM +0100, Matthew Wilcox wrote: > On Thu, Jun 18, 2026 at 07:10:45AM -0700, Christoph Hellwig wrote: > > On Tue, Jun 16, 2026 at 05:23:48PM +0000, Pranjal Shrivastava wrote: > > > AFAIU, the MM subsystem explicitly ensures that every valid struct page > > > is part of a folio. > > > > It is definitively not what the vision for the folio is, although if > > I'm not mistaken it actually is still true right now. > > It's not true, eg, for slab. While there's still a struct page there > for slab, there's no refcount and flags like PG_locked have different > meanings. You'll get into a lot of trouble trying to treat slabs as > folios (and that will include assertions tripping). True. But also not relevant for direct I/O user pinning. If we stopped having valid folios for anything mapped into userspace, iov_iter_extract_bvecs would run into problems, and we had the discussion before that at least right now it would be hard to fix. Also if iov_iter_extract_bvecs was used on kvec or bvec iters we could run into the slab problem. The block usage currently makes sure bvec iters are not handed to iov_iter_extract_bvecs, but there is no such thing for kvec vectors, although no one is using them for direct I/O right now. Not that I'd want to rely on that in the long run.