Re: Pending AIO work/patches

[Zach Brown]

>>(6) epoll - AIO integration (Zach Brown/Feng Zhou/wli)
>>	Status: Needs resurrection ?
> 
> 
> What are folks thoughts in this area?  Zach's patches took the approach of 
> making multishot iocbs possible, which helped avoid the overhead of plain 
> aio_poll's command setup, which was quite visible in pipetest.  Zach -- did 
> you do any benchmarking on your aio-epoll patches?

No, what little work I did on this was just pushing for stable
functionality.  I had a little test app that was still missing event
delivery occasionally.  I'm sure it'd be easy enough to track down.  It
still seems like a pretty reasonable translation of epoll event delivery
through the aio completion queue.  I'm not thrilled with the epoll edge
delivery semantics, though, it would be nice to make duplicate event
generation contigent on servicing an initial event.  EPOLLIN being
throttled until read activity is seen on the fd, that kind of thing.
Nontrivial work, of course.

>>(7) Vector AIO (aio readv/writev) (Yasushi Saito)
>>	Status: Needs resurrection ?
> 
> Zach also made some noises about this recently...

Yeah, I've got a patch working that adds CMD_AIO_P{WRITE,READ}V for ext3
via some aio->aio_p{read,werive}v ops.  It's currently against some
distro 2.6, but I'll port it up to current and post the patch.  It seems
pretty noncontroversial -- one obviously wants to scatter/gather
file-contiguous IO with tiny iovec elements, which bubble down well to
the generic fs/block helpers, rather than trying to get the various
layers to merge many large iocb submissions that can be found to be
file-contiguous.

- z
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/