public inbox for [email protected]
 help / color / mirror / Atom feed
From: Al Viro <[email protected]>
To: Pavel Begunkov <[email protected]>
Cc: Jens Axboe <[email protected]>,
	[email protected], [email protected],
	[email protected], [email protected],
	Christoph Hellwig <[email protected]>,
	Matthew Wilcox <[email protected]>,
	Ming Lei <[email protected]>,
	Johannes Weiner <[email protected]>
Subject: Re: [RFC 0/2] nocopy bvec for direct IO
Date: Wed, 9 Dec 2020 17:06:26 +0000	[thread overview]
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>

On Wed, Dec 09, 2020 at 02:19:50AM +0000, Pavel Begunkov wrote:
> The idea is to avoid copying, merging, etc. bvec from iterator to bio
> in direct I/O and use the one we've already got. Hook it up for io_uring.
> Had an eye on it for a long, and it also was brought up by Matthew
> just recently. Let me know if I forgot or misplaced some tags.
> 
> A benchmark got me 430KIOPS vs 540KIOPS, or +25% on bare metal. And perf
> shows that bio_iov_iter_get_pages() was taking ~20%. The test is pretty
> silly, but still imposing. I'll redo it closer to reality for next
> iteration, anyway need to double check some cases.
> 
> If same applied to iomap, common chunck can be moved from block_dev
> into bio_iov_iter_get_pages(), but if there any benefit for filesystems,
> they should explicitly opt in with ITER_BVEC_FLAG_FIXED.

To reiterate what hch said - this "opt in" is wrong.  Out-of-tree
code that does async IO on bvec-backed iov_iter, setting it up on
its own will have to adapt, that all.

iov_iter and its users are already in serious need of simplification
and cleanups; piling more on top of that would be a bloody bad idea.

Proposed semantics change for bvec-backed iov_iter makes a lot of sense,
so let's make sure that everything in tree can live with it, document
the change and switch to better semantics.

This thing should be unconditional.  Document it in D/f/porting and
if something out of tree complains, it's their problem - not ours.

      parent reply	other threads:[~2020-12-09 17:07 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-09  2:19 [RFC 0/2] nocopy bvec for direct IO Pavel Begunkov
2020-12-09  2:19 ` [PATCH 1/2] iov: introduce ITER_BVEC_FLAG_FIXED Pavel Begunkov
2020-12-09  8:36   ` Christoph Hellwig
2020-12-09  9:06     ` Christoph Hellwig
2020-12-09 11:54       ` Pavel Begunkov
2020-12-09 13:07     ` Al Viro
2020-12-09 13:37       ` Pavel Begunkov
2020-12-09 17:55         ` Christoph Hellwig
2020-12-09 18:24           ` Matthew Wilcox
2020-12-13 22:09             ` Pavel Begunkov
2020-12-09  2:19 ` [PATCH 2/2] block: no-copy bvec for direct IO Pavel Begunkov
2020-12-09  8:40   ` Christoph Hellwig
2020-12-09 12:01     ` Pavel Begunkov
2020-12-09 12:05       ` Christoph Hellwig
2020-12-09 12:03         ` Pavel Begunkov
2020-12-11 14:06     ` Johannes Weiner
2020-12-11 14:20       ` Pavel Begunkov
2020-12-11 15:38         ` Johannes Weiner
2020-12-11 15:47           ` Pavel Begunkov
2020-12-11 16:13             ` Johannes Weiner
2020-12-09 21:13   ` David Laight
2020-12-09  6:50 ` [RFC 0/2] nocopy " Christoph Hellwig
2020-12-09 11:54   ` Pavel Begunkov
2020-12-09 16:53 ` Jens Axboe
2020-12-13 22:03   ` Pavel Begunkov
2020-12-09 17:06 ` Al Viro [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 \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    [email protected] \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox