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

[Pavel Hrdina]

On Wed, Sep 27, 2017 at 02:24:12PM +0200, Pavel Hrdina wrote:
> 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

Ehm, I forgot to include the link to the "polling" discussion:

[1] <https://www.redhat.com/archives/libvir-list/2017-February/msg01084.html>

> --
> libvir-list mailing list
> libvir-list at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list

-------------- 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/4597775c/attachment-0001.sig>