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
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
