[Qemu-devel] Evaluating Disk IO and Snapshots

[Juergen Pfennig]

Hi,
THE FOLLOWING IS IMPORTANT (COMMENTS ARE WELCOME):

I will modifiy monitor.c to implement a "save" command. That command
will do:

    stop
    commit
    (rename the old vmstate file)
    savevm (from where it got loaded)

The commands commit and savevm will be modified to give progress 
report info, the same for qemu-img. A future improvement (which
is transparent to the user) could be to the avoid the commit at 
all and to use the new -snapshot file driver (see below) to 
remember the vm state. Also qemu-img would have to be enabled
to commit the -snapshot file and to extract the savevm file for
backward compatibility.

The following is just for information ...

I am still evaluating qemu, currently the disk IO. I am aware of some
proposed patches concerning the disk controler to enable windows to
use dma and async IO. I am not going to interfere with these.

What I found is that qcow has poor performance. I wrote my own driver
(which is intended only for -snapshot) and see signifcant improvements.
A 300 MByte file copy (win2003 xcopy /e between two real drives) takes
90 instead of 135 seconds. I will send the patch to the list after it
has matured for a while. The thing is linux only for mmap() is used.

Background: Windows massively uses the swap file - all dirty memory
gets written to swap after 30s, whereas linux is very lazy using 
it's swap file. For windows on qemu (best with -snapshot) swap io
performance really matters.

There is also a new implementation to generate temporary file names. 
The TMPDIR environment variable is taken into account. Reason (1):
programs must not assume that "/tmp" can/should be used. Some distros
(debian) propose the use of pam_tempdir (or however it is called).
Reason (2): matured versions of my driver will use 2 tmp files per
disk to avoid sparseness. As qemu for the moment has no config file
(which is good for the moment) environment variables might be used to
tweak the config.

Another 1..2% io speed improvement (here measured in CPU cycles) might be
possible by reorganizing the way how data is copied between the port and
the disk. The required changes are moderate. I will try a timing simulation
outside qemu and will report the result.

Yours Jürgen