We have found certain application scenarios where overriding of the default qemu host cache mode provides a substantial improvement in guest performance. In particular, disabling host caching of the file/dev backing a guest drive. A summary of performance metrics may be found below. Attached is a simple patch which adds general support for a "cache=*" attribute to be passed to qemu from libvirt as part of a xml <driver> element. It is parsed in a domain's xml definition as well as being generated during output of the same. For example: <disk type='file' device='disk'> <source file='/guest_roots/fc8.root'/> <target dev='hda'/> <driver name='qemu' type='qwerty' cache='none'/> </disk> where both the existing "type=*" and added "cache=*" attributes are optional and independent. Note this is only intended to serve as an internal hook allowing override of qemu's default cache behavior. At the present it is not proposed as an end-user documented/visible feature. -john Mark Wagner wrote:
This data is provided is provided by the Red Hat Performance team. It is intended to support the request for adding the required functionality to libvirt to allow for setting a storage parameter to control the caching behavior of QEMU. This value would be passed on the QEMU command line.
Our testing of commercial databases in a larger, Enterprise configuration (MSA, 16 cores, etc) has shown that the default QEMU caching behavior is not always the best. This set of data compares the drop off in performance of both writethrough and writeback cache compared to the nocache option. The main metric is transactions per minute (tpm). The other "axis" is the number of simulated users (x1000)
% nocache TPM Results K Users WT WB 10 60% 64% 20 66% 71% 40 68% 72% 60 71% 75% 80 74% 79% 100 76% 83%
From the above set of data, it is clear that the default behavior of QEMU is the worst performer out of the three cache options for this type of use case. It is also clear that we at minimum, 25% of the possible TPM performance just due to the cache setting.
-- john.cooper@redhat.com