1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
|
performance: 0.748
architecture: 0.578
user-level: 0.484
permissions: 0.461
device: 0.451
register: 0.440
PID: 0.438
assembly: 0.427
kernel: 0.415
graphic: 0.413
semantic: 0.411
vnc: 0.385
hypervisor: 0.384
virtual: 0.384
peripherals: 0.382
network: 0.363
ppc: 0.354
socket: 0.350
x86: 0.344
files: 0.343
mistranslation: 0.337
arm: 0.336
risc-v: 0.308
i386: 0.308
debug: 0.292
KVM: 0.291
VMM: 0.279
TCG: 0.278
boot: 0.268
cache=writeback on disk image doesn't do write-back
I noticed that qemu seems to have poor disk performance. Here's a test that has miserable performance but which should be really fast:
- Configure qemu to use the disk image with cache=writeback
- Configure a 2GiB Linux VM on an 8GiB Linux host
- In the VM, write a 4GiB file (dd if=/dev/zero of=/tmp/x bs=4K count=1M)
- In the VM, read it back (dd if=/tmp/x of=/dev/null bs=4K count=1M)
With writeback, the whole file should end up in the host pagecache. So when I read it back, there should be no I/O to the real disk, and it should be really fast. Instead, I see disk activity through the duration of the test, and the performance is roughly the native hard disk throughput (somewhat slower).
I'm using version 0.11.1, and this is my command line:
qemu-system-x86_64 -drive cache=writeback,index=0,media=disk,file=ubuntu.img -k en-us -m 2048 -smp 2 -vnc :3100 -usbdevice tablet -enable-kvm &
Can you please try reproducing with 0.12.1?
I'm using 0.12.1.2. With this command line:
qemu-system-x86_64 -drive cache=writeback,index=0,media=disk,file=ubuntu.img -k en-us -m 2048 -smp 2 -vnc :3102 -usbdevice tablet -enable-kvm &
Here's what I'm seeing:
With "dd if=/dev/zero of=./x bs=1024k count=1024", I get at best 29 MiB/sec.
This fits in the VM, so with "dd if=/dev/zero of=./x bs=1024k count=1024", which spills into the host, I get at best 25 MiB/sec. (I am aware that with the expanding qcow2 disk image, there's also some overhead for allocating space during the write, so I run the same test multiple times and report the best result.)
Since I'm using writeback, I would expect to see much faster write performance. This is slower than the host's disk performance with fsync involved. Is there an fsync going on here? Is dd doing an fsync? That should sync the VM's disk. But then is there an ATA command to sync the drive that qemu interprets as a request to sync the disk image? It would be "safe" to take this hint, but since I'm explicitly requesting writeback, I'm not expecting "safe". I'm intentionally defeating "safe" for the sake of performance, with full knowledge of the risks.
With "dd if=./x of=/dev/null bs=1024k count=1024", it varies a LOT, but I've gotten as much as 4.9GiB/sec and as little as 2.5GiB/sec. This is WAY better than what I was getting with 0.11.1.
With "dd if=./x of=/dev/null bs=1024k count=4096", the best I get is 460MiB/sec. That's still very good. Could be better, but the overhead of emulating SATA has got to be really high under any circumstances.
Using a VM imposes a lot of overhead that makes the guest OS quite a bit slower than running it directly on the hardware. I'm trying to make up for this by using the rest of my hosts RAM (more or less) as a huge disk cache.
QEMU 0.11 / 0.12 is pretty much outdated nowadays ... can you still reproduce this issue with the latest version of QEMU?
[Expired for QEMU because there has been no activity for 60 days.]
|