On Wed, 2006-06-28 at 22:24 -0700, Andrew Warfield wrote:
> > I like the idea of block servers in userspace, but I'm curious.
> > When I
> > wrote the simple share block server I couldn't see an obvious
> > justification for multiple outstanding requests (with AIO/threads and
> > all that entails), so I went for the trivial single request approach.
> > It seems to me that the backend doesn't have much information the front
> > end doesn't have.
>
> Hi Rusty,
>
> not sure I see what you are asking. A very early version of the
> code just did synchronous dispatch (one blocking request at a time)
> and was, as you might expect, very slow. You clearly want to keep the
> block request queues as full as possible to amortize seeks...
Last I looked the blkif front end, it uses a noop I/O scheduler, which
means that the only one doing scheduling is the backend. I can easily
imagine that if the backend is synchronous, this would be slow.
However, it's not clear to me that doing scheduling in the backend will
generally be faster than doing it in the front end. I suppose it should
be, if the backend domain were serving multiple frontends from the same
device.
> AIO just
> lets me issue batches of requests at once, and so minimizes context
> switching through userland -- which was something I was worried about
> causing overhead on x86_64. I don't really think it adds that much
> complexity.
Sure, I would have used a pool of processes because I'm old-fashioned,
but AIO is probably a better choice for multiple requests at once.
Cheers!
Rusty.
--
Help! Save Australia from the worst of the DMCA: http://linux.org.au/law
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home