From: Joel Becker <jlbec@evilplan.org>
To: Avi Kivity <avi@exanet.com>
Cc: Yasushi Saito <ysaito@hpl.hp.com>,
linux-aio@kvack.org, linux-kernel@vger.kernel.org,
suparna@in.ibm.com, Janet Morgan <janetmor@us.ibm.com>
Subject: Re: [PATCH 1/2] aio: add vectored I/O support
Date: Sat, 16 Oct 2004 17:28:36 +0100 [thread overview]
Message-ID: <20041016162836.GG17142@parcelfarce.linux.theplanet.co.uk> (raw)
In-Reply-To: <4170DF18.50004@exanet.com>
On Sat, Oct 16, 2004 at 10:43:04AM +0200, Avi Kivity wrote:
> Using IO_CMD_READ for a vector entails
>
> - converting the userspace structure (which might well an iovec) to iocbs
Why create an iov if you don't need to?
> - merging the iocbs
I don't see how this is different than merging iovs. Whether an
I/O range is represented by two segments of an iov or by two iocbs, the
elevator is going to merge them. If the userspace program had the
knowledge to merge them up front, it should have submitted one larger
segment.
> - generating multiple completions for the merged request
Fair enough.
> - coalescing the multiple completions in userspace to a single completion
You generally have to do this anyway. In fact, it is often far
more efficient and performant to have a pattern of:
submit 10;
reap 3; submit 3 more;
reap 6; submit 6 more;
repeat until you are done;
than to wait on all 10 before you can submit 10 again.
> error handling is difficult as well. one would expect that a bad sector
> with multiple iocbs would only fail one of the requests. it seems to be
> non-trivial to implement this correctly.
I don't follow this. If you mean that you want all io from
later segments in an iov to fail if one segment has a bad sector, I
don't know that we can enforce it without running one segment at a
time. That's terribly slow.
Again, even if READV is a good idea, we need to fix whatever
inefficiencies io_submit() has. copying to/from userspace just can't be
that slow.
Joel
--
"When choosing between two evils, I always like to try the one
I've never tried before."
- Mae West
http://www.jlbec.org/
jlbec@evilplan.org
next prev parent reply other threads:[~2004-10-16 16:28 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-10-14 20:10 Yasushi Saito
2004-10-16 3:13 ` Joel Becker
2004-10-16 5:18 ` Avi Kivity
2004-10-16 5:37 ` Joel Becker
2004-10-16 8:43 ` Avi Kivity
2004-10-16 16:28 ` Joel Becker [this message]
2004-10-16 17:29 ` Avi Kivity
2004-10-17 0:14 ` Joel Becker
2004-10-17 6:25 ` Avi Kivity
2004-10-16 12:05 ` William Lee Irwin III
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=20041016162836.GG17142@parcelfarce.linux.theplanet.co.uk \
--to=jlbec@evilplan.org \
--cc=avi@exanet.com \
--cc=janetmor@us.ibm.com \
--cc=linux-aio@kvack.org \
--cc=linux-kernel@vger.kernel.org \
--cc=suparna@in.ibm.com \
--cc=ysaito@hpl.hp.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome