[libvirt] [PATCH v6 0/2] Add support for qcow2 cache

[Pavel Hrdina]

On Tue, Sep 26, 2017 at 05:06:37PM -0400, John Ferlan wrote:
> 
> 
> On 09/18/2017 11:45 PM, Liu Qing wrote:
> > Qcow2 small IO random write performance will drop dramatically if the l2
> > cache table could not cover the whole disk. This will be a lot of l2
> > cache table RW operations if cache miss happens frequently.
> >  
> > This patch exports the qcow2 driver parameter
> > l2-cache-size/refcount-cache-size, first added in Qemu 2.2, and
> > cache-clean-interval, first added in Qemu 2.5, in libvirt.
> > 
> > change since v4: removed unnecessary cache error check
> > 
> > Liu Qing (2):
> >   conf, docs: Add qcow2 cache configuration support
> 
> According to what you added for the v5 - there's an upstream bz that
> could be associated with this work.  Is this something that should be
> added to the commit message so that we can "track" where the idea comes
> from?
> 
> Beyond that - I agree setting policy is not the business we want to be
> in. I just figured I'd throw it out there. I didn't read all of the qemu
> links from the bz about thoughts on this - too many links too much to
> follow not enough time/desire to think about it.
> 
> I'm not against pushing these patches, but would like to at least make
> sure Peter isn't 100% against them. I agree the attributes are really
> painful to understand, but it's not the first time we've added some
> attribute that comes with a beware of using this unless you know what
> you're doing.

I'm still not convinced that this is something we would like to expose
to users.  It's way too low-level for libvirt XML.  I like the idea to
allow 'max' as possible value in QEMU and that could be reused by
libvirt.

One may argue that having two options as "max storage" or
"max performace" isn't good enough and they would like to be able to
tune it for they exact needs.  Most of the users don't care about the
specifics and they just need a performance or not.

I attempted to introduce "polling" feature [1] for iothreads but that
was a bad idea and too low-level for libvirt users and configuring exact
values for qcow2 cache seems to be the same case.

Adding an element/attribute into XML where you would specify whether you
care about performance or not isn't a policy.  Libvirt will simply use
some defaults or configure the maximum performance.  For fine-grained
tuning you can use <qemu:arg value='...'/> like it was suggested for
"polling" feature.

Pavel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20170927/361e6f69/attachment-0001.sig>