Re: [PATCH v2 6/7] nfs: Optimize direct I/O to use folios for requests

From: Christoph Hellwig

Date: Fri Jun 26 2026 - 02:56:54 EST


[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.