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(a)redhat.com