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/
Home Products Support Community News


[Xen-devel] Re: VT is comically slow

To: xen-devel@xxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Re: VT is comically slow
From: Anthony Liguori <anthony@xxxxxxxxxxxxx>
Date: Fri, 07 Jul 2006 07:19:23 -0500
Delivery-date: Fri, 07 Jul 2006 05:25:02 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
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: <20060707014350.19F2C2F91A@xxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
User-agent: Pan/ (As She Crawled Across the Table (Debian GNU/Linux))
On Thu, 06 Jul 2006 17:43:50 -0800, alex wrote:

> Anthony Liguori wrote:
>> 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.
> The QEMU code that we use doesn't go through the dom0 buffer cache, we
> modified the code to use O_DIRECT.  Can't user buffer cache and
> accelerated drivers (they go right to the disk) together, it can cause
> disk corruption.  The performance numbers we get from this version of
> QEMU is still 4 to 6 times slower that native disk I/O.

Sorry, I should have been more clear.  I presume that your drivers are a
lot like the normal paravirt drivers.  This means that you're injecting
bio's into the host that point directly to the memory in the guest.

Just using O_DIRECT wouldn't be enough in QEMU.  You would also have to
have functioning DMA (which appears broken in Xen).  Proper async support
would help too.


Anthony Liguori

>> 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.
> You might be right, however even with pipelining and async I/O, I don't
> think it is going to get close to native I/O numbers.  I guess we'll
> just have to wait and see

> Best,
> -Alex V.

Xen-devel mailing list

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