On 10/31/2011 04:26 PM, Kevin Wolf wrote: > Am 31.10.2011 16:07, schrieb Richard W.M. Jones: >> On Mon, Oct 31, 2011 at 10:18:50AM +0100, Kevin Wolf wrote: >>> Am 30.10.2011 21:59, schrieb Richard W.M. Jones: >>>>> I've pulled most of the information you requested. See above. I >>>>> don't see any specific cache settings on either machine. Is there >>>>> somewhere I would see the default setting on the machine? >>>> >>>> I'm out of the loop on what the default caching policy is these days. >>>> Hopefully libvirt is at least choosing a safe one. >>> >>> cache=writethrough is the default. And indeed this is the safest option, >>> and at the same time by far the slowest option. I would expect that you >>> get much better write performance with cache=none. >>> >>> Note however that older guests OSes cannot deal correctly with disks >>> that have a volatile write cache, like cache=none emulates. This means >>> that in case of a host crash and with some bad luck, your guest might >>> experience file system corruption. >>> >>> Recent guest OSes are safe in this respect and can be used with >>> cache=none or cache=writeback in order to improve performance without >>> any such risk. >> >> Just FYI, here is how libvirt XML types are mapped to qemu types, >> found by examining the libvirt code: >> >> libvirt old qemu modern qemu >> >> none cache=off cache=none >> writeback cache=on cache=writeback >> writethrough cache=off cache=writethrough >> directsync cache=off cache=directsync (if supported by qemu) >> unsafe cache=off cache=unsafe (if supported by qemu) > > cache=off is a strange fallback for unsafe... > >> I tested this to see what libvirt would actually use with my fairly >> recent qemu-kvm, and what sort of timings I would get: > > What does fairly recent mean? cache=unsafe is supported since 0.13. If > it doesn't work this might indicate a libvirt bug. > >> libvirt MB/s modern qemu command line >> >> (no setting) 29 (nothing) >> none 39 cache=none >> writeback 24* cache=writeback >> writethrough 28 cache=writethrough >> directsync [did not work for me -- "unknown disk cache mode"] >> unsafe [did not work for me -- "unknown disk cache mode"] >> >> * = large variability in this result >> >> What's also interesting is that performance today with no cache >> setting is slower than it was yesterday, even though I'm not running >> anything significantly different on my laptop. >> >> Kevin, I'm using 'dd ... conv=fsync' for these tests. What's a good, >> reliable method for testing read and write speeds? > > Depends on what you want to test, obviously. conv=fsync will be very > much in favour of cache=writethrough because you force all other caching > options to do the disk flushes as well that make writethrough so slow. > > When I use dd for testing, I usually use oflag=direct to bypass the > guest's page cache, but don't issue any fsyncs. You should see that the > writeback modes (none/writeback/unsafe) performs quite a bit better with > that, while I'd expect writethrough to stay on about the same level.
FYI I've seen really strange behavior when I tried to do some benchmarking so I'm interested in this topic as well. I opened a bug for my problems: https://bugzilla.redhat.com/show_bug.cgi?id=750202 Regards, Dennis _______________________________________________ virt mailing list [email protected] https://admin.fedoraproject.org/mailman/listinfo/virt
