[Xen-devel] Re: [kvm-devel] [PATCH RFC 3/3] virtio infrastructure: example block driver

[Troy Benjegerdes <hozer@xxxxxxxxx>]

On Thu, May 31, 2007 at 02:57:27PM +0200, Carsten Otte wrote:
> Rusty Russell wrote:
> > Example block driver using virtio.
> > 
> > The block driver uses outbufs with sg[0] being the request information
> > (struct virtio_blk_outhdr) with the type, sector and inbuf id.  For a
> > write, the rest of the sg will contain the data to be written.
> > 
> > The first segment of the inbuf is a result code (struct
> > virtio_blk_inhdr).  For a read, the rest of the sg points to the input
> > buffer.
> > 
> > TODO:
> >     1) Ordered tag support.
> Implementing a do_request function has quite a few disadvantages over 
> hooking into q->make_request_fn. This way, we have the device plug 
> (latency), request merging, and I/O scheduling inside the guest.
> It seems preferable to do that in the host, especially when requests 
> of multiple guests end up on the same physical media (shared access, 
> or partitioned).

This kind of a claim needs some benchmark data to document it.

I'll make the counterclaim that you *should* be doing I/O scheduling in
the guest, both to be able to test new I/O schedulers, and to provide
a set of pre-scheduled I/Os so the host has to do less work.

If someone really needs the host to be doing I/O scheduling, and not the
guest, then why are they using virtualization in the first place?

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel