All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avi Kivity <avi@exanet.com>
To: Joel Becker <jlbec@evilplan.org>
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 10:43:04 +0200	[thread overview]
Message-ID: <4170DF18.50004@exanet.com> (raw)
In-Reply-To: <20041016053721.GD17142@parcelfarce.linux.theplanet.co.uk>

Joel Becker wrote:

>On Sat, Oct 16, 2004 at 07:18:45AM +0200, Avi Kivity wrote:
>  
>
>>It is a huge performance win, at least on the 2.4-based RHEL kernel. 
>>Large reads (~256K) using 4K iocbs are very slow on a large RAID, while 
>>after I coded a similar patch I got a substantial speedup.
>>    
>>
>
>	I'd think we should fix the submission path instead.  Why create
>iovs _and_ iocbs when we only need to create one?  And even if we
>decided aio_readv() was still nice to keep, we'd want to fix this
>inefficiency in io_submit().
>
>  
>
Using IO_CMD_READ for a vector entails

- converting the userspace structure (which might well an iovec) to iocbs
- copying all those iocbs to the kernel
- merging the iocbs
- generating multiple completions for the merged request
- copying the completions to userspace
- coalescing the multiple completions in userspace to a single completion

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.

IO_CMD_PREADV, by contrast, is very simple, intuitive, and efficient.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.


  reply	other threads:[~2004-10-16  8:43 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-14 20:10 [PATCH 1/2] aio: add vectored I/O support 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 [this message]
2004-10-16 16:28         ` Joel Becker
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=4170DF18.50004@exanet.com \
    --to=avi@exanet.com \
    --cc=janetmor@us.ibm.com \
    --cc=jlbec@evilplan.org \
    --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 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.