[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH 2/2 v2] Direct IDE I/O

From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH 2/2 v2] Direct IDE I/O
Date: Mon, 03 Dec 2007 12:08:19 -0600
User-agent: Thunderbird (X11/20071022)

Jamie Lokier wrote:
Paul Brook wrote:
On Monday 03 December 2007, Samuel Thibault wrote:
Anthony Liguori, le Mon 03 Dec 2007 09:54:47 -0600, a écrit :
Have you done any performance testing?  Buffered IO should absolutely
beat direct IO simply because buffered IO allows writes to complete
before they actually hit disk.
Since qemu can use the aio interface, that shouldn't matter.
Only if the emulated hardware and guest OS support multiple concurrent commands. IDE supports async operation, but not concurrent commmands. In practice this means you only get full performance if you're using the SCSI emulation.

With the IDE emulation, when the emulated "disk write cache" flag is
on it may be reasonable to report a write as completed when the AIO is
dispatched, without waiting for the AIO to complete.
An IDE flush cache command would wait for all outstanding write AIOs
to complete, and then issue a flush cache (fdatasync) to the real
device before reporting it has completed.

That's roughly equivalent to what an IDE disk with write caching does,
and it would provide exactly the guarantees for safe storage to the
real physical medium that a journalling filesystem or database in the
guest requires.

If a guest doesn't use journalling with IDE write cache safely
(e.g. 2.4 Linux and earler), it can simply turn off the IDE "disk
write cache" flag, which is what it has to do on a real physical disk

Terminating the qemu process abruptly might cancel some AIOs, but even
that is ok, as it's equivalent to pulling the power on a real disk
with uncommitted cached writes.

Except that in an enterprise environment, you typically have battery backed disk cache. It really doesn't matter though b/c in QEMU today, submitting the request blocks until it's completed anyway (which is nearly instant anyway since I/O is buffered).


Anthony Liguori

-- Jamie

reply via email to

[Prev in Thread] Current Thread [Next in Thread]