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

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>

From the discussion thus far for qcow2 cache the difference here is that