From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: VT is comically slow Date: Fri, 07 Jul 2006 07:19:23 -0500 Message-ID: References: <20060707014350.19F2C2F91A@ws6-3.us4.outblaze.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org 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. Regards, 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.