WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [PATCH] Blktap: Userspace file-based image support. (RFC


On 30 Jun 2006, at 14:35, Stephen C. Tweedie wrote:

Hi,

On Thu, 2006-06-29 at 07:34 -0700, Andrew Warfield wrote:

The linux libaio stuff is pretty good actually. Requests map rather
directly down onto the kernel bio interface, so with aio the userland
block back code is doing a very similar thing to the in-kernel driver.

Yep. I noticed that the blktap patch includes adding EPOLL to kernel
aio, though, and that has not (yet) been accepted upstream; is that
something that is absolutely necessary for blktap, or could you live
without it?

Without the completion event poll an alternative was to block on io_getevents for the batch to complete, or to periodically test for queued responses. This approach was definitely preferable since it fit very nicely into the asynch architecture we were working towards for the userspace drivers. Without the completion poll, the performance would most likely degrade, although we haven't done any tests to measure by how much.

Is there any movement towards getting that upstream, since otherwise
we're introducing dependencies on core kernel infrastructure that is not
guaranteed to persist upstream? It looks like the sort of thing that
would be entirely reasonable upstream: EPOLL for aio seems to make a ton
of sense.

Agreed. We'd like to see the EPOLL facility adopted in the mainstream AIO architecture. The current patch was submitted on the linux-aio list in repsonse to a query we sent about a month ago, however I don't believe there has been any movement to officially add it. It's on our agenda to follow-up with the AIO folks since it definitely should belong in the mainstream kernel rather than as a xen patch.

- Julian
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
<Prev in Thread] Current Thread [Next in Thread>