Messages in this thread | | | Date | Sat, 16 Oct 2004 17:28:36 +0100 | From | Joel Becker <> | Subject | Re: [PATCH 1/2] aio: add vectored I/O support |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |