Re: [PATCH/RFC 6/9] virtual block device driver

[Avi Kivity <avi-atKUWr5tajBWk0Htik3J/w@public.gmane.org>]

Carsten Otte wrote:
>
>>> System call latency adds to the in-kernel approach here.
>> I don't understand this.
> What I meant to state was: If the host side of the block driver runs 
> in userspace, we have the extra latency to leave the kernel system 
> call context, compute on behalf of the user process, and do another 
> system call (to drive the IO). This extra overhead does not show when 
> handling IO requests from the guest in the kernel.
>

Well, this argument seems to be in favor of not using an fd ;)

Actually, an fd is usable when storing a disk in a raw file.  But qemu 
supports non-raw (formatted) disk images, which have additional features 
like snapshots.  The fd alone does not contain enough information.


>
>> I/O may be slow, but you can have a lot more disks than cpus.
>>
>> For example, if an I/O takes 1ms, and you have 100 disks, then you 
>> can issue 100K IOPS.  With one hypercall per request, that's ~50% of 
>> a cpu (at about 5us per hypercall that goes all the way to 
>> userspace).  That's not counting the overhead of calling io_submit().
> Even when a hypercall round-trip takes as long as 5us, and even if you 
> have 512byte per biovec only (we use 4k blocksize), I don't see how 
> this gets a performance problem:
> With linear read/write you get 200.000 hypercalls per second with 128 
> kbyte per hypercall. That's 25.6 GByte per second per CPU. With random 
> read (worst case: 512 byte per hypercall) you still get 100 MByte per 
> second per CPU. There are tighter bottlenecks in the IO hardware afaics.
>

If all you do is I/O, sure.  If you want to limit I/O cpu overhead to 
10%, the raw bandwidth becomes 10 MB/s/cpu.

(bandwidth isn't a good measure for random I/O, IOPS is the interesting 
metric)

Both the guest and host will favor batched requests.  It's a shame to 
deny that because of a simplistic protocol.


-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/