On Tue, 2005-12-20 at 20:00 +0200, Avi Kivity wrote:Possibly a library can do that (placing the context in thread local storage), but I see your point.
You can io_submit() a list of IO_CMD_PREAD[V]s and immediately io_getevents() them. In addition to specifying different file offsets you can mix reads and writes, mix file descriptors, and reap nonblocking events quickly (by specifying a timeout of zero).
Sure, it's two syscalls instead of one, but it's much more flexibles, and databases should be using aio anyway. Oh, and no kernel changes needed, apart from merging vectored aio.
Yes. We discussed this also earlier. Using AIO is the alternative.
But using AIO is not simple as doing preadv()/pwritev() for the
applications doesn't care about using AIO. AIO needs extra coding
to setup context, iocb, submits and getevents etc..
And also, inside the kernel - AIO requests go through lots ofI'd be surprised if this isn't dominated by the cost of serving the request, even from cache.
code/routines -- before coming to ->aio_read() -- which I was
planning to avoid by having a direct syscall to do preadv/pwritev.
BTW, we still don't have vectored AIO support in the kernel.Hopefully they will supercede aio_read/aio_write?
Zack is working on it - which would add another set of
file operations aio_readv/aio_writev.