[libvirt] patch: allow disk cache mode to be specified in a domain's xml definition.

[john cooper]

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 at redhat.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: libvirt-drive-cache-09010901.patch
Type: text/x-patch
Size: 5972 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20090116/c00c4b31/attachment-0001.bin>