All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rik van Riel <riel@surriel.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: linux-kernel@vger.kernel.org, kernel-team@meta.com,
	Andrew Morton	 <akpm@linux-foundation.org>,
	David Hildenbrand <david@kernel.org>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	John Hubbard <jhubbard@nvidia.com>, Peter Xu <peterx@redhat.com>,
		linux-mm@kvack.org
Subject: Re: [RFC PATCH v3 0/8] batch lookups in follow_page_mask()
Date: Wed, 26 Aug 2026 09:36:51 -0400	[thread overview]
Message-ID: <282ef22ff621eb5d1f079b89d067dde29686e08b.camel@surriel.com> (raw)
In-Reply-To: <ao5t8lxaCWQvph-l@infradead.org>

On Tue, 2026-08-25 at 21:39 -0700, Christoph Hellwig wrote:
> On Tue, Aug 25, 2026 at 09:37:09AM -0400, Rik van Riel wrote:
> > > And what many including the most performance critical callers
> > > want
> > > instead is really a single bio_vec.  Maybe we can go the extra
> > > step
> > > for
> > > that, as it would reduce the number of calls into gup
> > > significantly.
> > > 
> > Which code are you referring to here?
> > 
> > blk_rq_map_user() seems to end up calling pin_user_pages_fast(),
> > via iov_iter_extract_user_pages, and it directly fills in the
> > bio_vec's pages array.
> > 
> > Is there another performance critical path that goes
> > through the slower get_user_pages() path?
> 
> The other callers of iov_iter_extract_bvecs matter more, but this is
> the main user.
> 
> And iov_iter_extract_bvecs right now is very inefficient when used
> on larger folios,

I think it would be possible to create a path
into follow_page_mask() that passes a bio_vec,
and where we fill in the bio_vec fields the
same way bvec_set_page() does.

Then iov_iter_extract_bvecs would no longer
need to iterate over the pages returned by
get_user_pages_fast.

That seems like a follow-up series though,
and we need to think carefully about whether
we would also want to unify part of the 
gup_fast and gup code.

Currently the gup code depends on locking
to keep page tables from going away, while
the gup_fast code depends on disabling irqs.

-- 
All Rights Reversed.


      parent reply	other threads:[~2026-08-26 13:37 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-11  2:51 [RFC PATCH v3 0/8] batch lookups in follow_page_mask() Rik van Riel
2026-08-11  2:51 ` [RFC PATCH v3 1/8] mm/gup: break out gup_fill_pages() helper Rik van Riel
2026-08-11  2:51 ` [RFC PATCH v3 2/8] mm/gup: convert follow_page_mask() to return a long Rik van Riel
2026-08-11  2:51 ` [RFC PATCH v3 3/8] mm/gup: split follow_page_pte_commit() out of follow_page_pte() Rik van Riel
2026-08-12 11:50   ` David Hildenbrand (Arm)
2026-08-12 13:02     ` Rik van Riel
2026-08-12 13:23       ` David Hildenbrand (Arm)
2026-08-12 16:19         ` Rik van Riel
2026-08-21 17:38         ` Rik van Riel
2026-08-21 22:04           ` John Hubbard
2026-08-22 13:20             ` Rik van Riel
2026-08-22 21:31               ` John Hubbard
2026-08-24 13:20                 ` Rik van Riel
2026-08-11  2:51 ` [RFC PATCH v3 4/8] mm/gup: break out follow_one_pte() helper Rik van Riel
2026-08-11  2:51 ` [RFC PATCH v3 5/8] mm/gup: fill the pages array outside the pud/pmd lock Rik van Riel
2026-08-11  2:51 ` [RFC PATCH v3 6/8] mm/gup: return a huge page's full count from follow_page_mask() Rik van Riel
2026-08-11  2:51 ` [RFC PATCH v3 7/8] mm/gup: walk multiple PTEs per follow_page_pte() call Rik van Riel
2026-08-11  2:51 ` [RFC PATCH v3 8/8] mm/gup: batch contiguous same-folio PTEs into one refcount grab Rik van Riel
2026-08-12 11:41 ` [RFC PATCH v3 0/8] batch lookups in follow_page_mask() David Hildenbrand (Arm)
2026-08-25  7:52 ` Christoph Hellwig
2026-08-25 13:37   ` Rik van Riel
2026-08-26  4:39     ` Christoph Hellwig
2026-08-26  7:35       ` Christoph Hellwig
2026-08-26  8:27         ` David Hildenbrand (Arm)
2026-08-26 13:36       ` Rik van Riel [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=282ef22ff621eb5d1f079b89d067dde29686e08b.camel@surriel.com \
    --to=riel@surriel.com \
    --cc=akpm@linux-foundation.org \
    --cc=david@kernel.org \
    --cc=hch@infradead.org \
    --cc=jgg@ziepe.ca \
    --cc=jhubbard@nvidia.com \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peterx@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.