On Thu, 06 Jul 2006 11:16:18 -0800, alex wrote:
> We (Virtual Iron) are in a process of developing accelerated drivers for
> the HVM guests. Our goal for this effort is to get as close to native
> performance as possible and to make paravirtualization of guests
> unnecessary. The drivers currently support most flavors of RHEL, SLES and
> Windows. The early performance numbers are encouraging. Some numbers are
> many times faster than QEMU emulation and are close to native performance
> numbers (and we are just beginning to tune the performance).
I don't think paravirtual drivers are necessary for good performance.
There are a number of things about QEMU's device emulation that are less
than ideal.
Namely, QEMU's disk emulation is IDE w/DMA. Apparently, DMA is busted
right now but even if it worked, IDE only allows one outstanding request
at a time (which doesn't let the host scheduler do it's thing properly).
Emulating either SCSI (which is in QEMU CVS) or SATA would allow multiple
outstanding requests which would be a big benefit.
Also, and I suspect this has more to do with your performance numbers,
QEMU currently does disk IO via read()/write() syscalls on an fd that's
open()'d without O_DIRECT. This means everything's going through the page
cache.
I suspect that SCSI + linux-aio would result in close to native
performance. Since SCSI is already in QEMU CVS, it's not that far off.
I think that the same applies to network IO but I'm not qualified to
comment on what things are important there.
Regards,
Anthony Liguori
> Just to give people a flavor of the performance that we are getting,
> here are some preliminary results on Intel Woodcrest (51xx series), with
> a Gigabit network, with SAN storage and all of the VMs were 1 CPU. These
> numbers are very early, disks numbers are very good and we are still
> tuning the network numbers.
>
> Bonnie-SAN - bigger is better RHEL-4.0 (32-bit) VI-accel
> RHEL-4.0(32-bit) Write, KB/sec 52,106
> 49,500 Read, KB/sec 59,392
> 57,186
>
> netperf - bigger is better RHEL-4.0 (32-bit) VI-accel
> RHEL-4.0(32-bit) tcp req/resp (t/sec) 6,831
> 5,648
>
> SPECjbb2000 - bigger is better RHEL-4.0 (32-bit) VI-accel
> RHEL-4.0(32-bit) JRockit JVM thruput 43,061
> 40,364
>
> This code is modeled on Xen backend/frontend architecture concepts and
> will be GPLed.
>
> -Alex V.
>
> Alex Vasilevsky
> Chief Technology Officer, Founder
> Virtual Iron Software, Inc
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home