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

Avi Kivity
2007-05-16T10:01:16Z

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