Ben,
Currently there is no way to initiate an aio readv/writev in 2.5. There
were no aio_readv/writev calls in 2.4 either - I'm wondering if there
was any particular reason for excluding readv/writev operations from aio ?
The read/readv paths have anyway been merged for raw/O_DIRECT and
regular file read/writes. So why not expose the vector read/write to the
user by adding the IOCB_CMD_PREADV/IOCB_CMD_READV and
IOCB_CMD_PWRITEV/IOCB_CMD_WRITEV commands to the aio set. Without that,
raw/O_DIRECT readv users would need to unnecessarily cycle through their
iovecs at a library level submitting them individually.
For larger iovecs, user/library code would needlessly deal with multiple
completions. While I'm not sure of the performance impact of the absence
of aio_readv/writev, it seems easy enough to provide.
Most of the functions are already in place. We would only
need a way to pass the iovec through the iocb.
I was thinking of something like this:
struct iocb {
+union {
__u64 aio_buf
+ __u64 aio_iovp
+}
+union {
__u64 aio_nbytes
+ __u64 aio_nsegs
+}
allowing the iovec * & nsegs to be passed into sys_io_submit. Some code
would be added (within case handling of IOCB_CMD_READV within
io_submit_one) to copy & verify the iovec pointers and then call
aio_readv/aio_writev (if its defined for the fs).
What do you think ? I wanted to get some feedback before trying to code
this up.
While we are on the topic of expanding aio operations, what about
providing IOCB_CMD_READ/WRITE, distinct from their pread/pwrite
counterparts ? Do you think thats needed ?
- Shailabh
-
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/
This archive was generated by hypermail 2b29 : Mon Sep 23 2002 - 22:00:31 EST