Hi,
On Fri, 2006-10-06 at 08:25 +0100, Jan Beulich wrote:
> Could anyone give a description (and reason it is needed for Xen, if that's
> not obvious from the description) for each of
>
> blktap-aio-16_03_06.patch
The blktap userland server (tapdisk) submits IO requests via kernel AIO,
but also waits for network/evtchn events via file descriptors. And
alas, the kernel has no way to wait for AIO and fd wakeups in a single
syscall.
This patch implements aio-for-poll --- it's a new core kernel ABI which
allows a temporary fd to be associated with an AIO IO context, so you
can wait on AIO and normal fds via a single select() call. But this ABI
has been vetoed upstream.
Upstream has given initial approval to an alternative means whereby
instead of submitting a poll() for AIO, you submit an AIO request for
poll. Then, io_getevents() can wait for both fd and AIO activity. But
that functionality is still not upstream.
We did not want to include the non-approved AIO+poll mechanism in our
own Fedora kernels, so as a workaround, I've coded up a simple patch
which makes tapdisk spawn a separate thread for AIO events, and return
wakeups via a pipe fd to the main event loop when AIO arrives. That
works fine as a temporary measure to allow us to ship blktap without the
AIO/poll stuff resolved upstream; but longer term, Jeff Moyer has been
talking to the AIO people to get epoll-for-AIO merged. I'm not sure of
the status of that work though, it may well have stalled.
I can post the AIO-thread patch here if anyone's interested; I didn't
post it as part of my recent blktap changes because (a) Xen upstream
doesn't need it, it carries the aio-for-poll patch instead; and (b) the
_right_ answer for Xen is eventually to use an upstream-blessed poll-
for-aio patch instead.
Cheers,
Stephen
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home