WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] VT is comically slow

To: "alex@xxxxxxxxxxxxxxx" <alex@xxxxxxxxxxxxxxx>
Subject: Re: [Xen-devel] VT is comically slow
From: "Rami Rosen" <rosenrami@xxxxxxxxx>
Date: Mon, 10 Jul 2006 10:51:20 +0300
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Delivery-date: Mon, 10 Jul 2006 00:51:42 -0700
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dCTPwIeo3iVVkspmOdsqQVQsNh0NXcXLD6tJIEdsmzhPMkeBfV9lJ9W1gDnC2GQTAnE6CLMcyKY+RKCYOpUyxvChnctQ8Hj+JkCHkxmVJmW+3eBz5Hjb5WBUujVp/XgLqaZqiPFBDZ5YEj5U5x5EzMr+vx/yN+mu50wq/Bkv8rA=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20060706191618.3CCF02F9B5@xxxxxxxxxxxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
References: <20060706191618.3CCF02F9B5@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Hello,

This code is modeled on Xen backend/frontend architecture concepts and will be
GPLed.

A little question for clarification, if I may:
These accelerated drivers, as I underastand, are running in Dom0.
(as domU runs unmodified OS kernels).
I assume that you are talking about generic drivers (like a driver for
IDE, driver
a driver for Net, etc) which will work in
conjunction with the real drivers ; am I right ?
or are these hardware specific drivers (like
one driver for e1000 nic, a driver for tg3 nic,a driver for realtek nic, etc.)?

Regards,
Rami Rosen

On 7/6/06, alex@xxxxxxxxxxxxxxx <alex@xxxxxxxxxxxxxxx> wrote:

Rik van Riel wrote:
> VT by itself seems fine, but once a VT domain is running a workload that
> is network intensive combined with a disk/cpu intensive workload, things
> get incredibly slow.
>
> Operations that take less than a second with either workload running
> alone can now take many seconds, sometimes the better part of a minute!
>
> Is this some limitation of the qemu device model?

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).

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


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

<Prev in Thread] Current Thread [Next in Thread>