On Mon, Sep 18, 2017 at 09:49:36 -0400, John Ferlan wrote:
>
>
> On 09/14/2017 01:08 AM, Liu Qing wrote:
> > Random write IOPS will drop dramatically if qcow2 l2 cache could not
> > cover the whole disk. This patch gives libvirt user a chance to adjust
> > the qcow2 cache configuration.
> >
> > Three new qcow2 driver parameters (l2-cache-size, refcount-cache-size
> > and cache-clean-interval) are added as attributes to a new <qcow2>
> > subelement for a <driver name='qemu' type='qcow2'...> of a <disk>
> > element. The QEMU source docs/qcow2-cache.txt provides the guidelines
> > for defining/configuring values for each.
> >
> > Signed-off-by: Liu Qing <liuqing@xxxxxxxxxx>
> > ---
> > docs/formatdomain.html.in | 41 +++++++++
> > docs/schemas/domaincommon.rng | 35 ++++++++
> > src/conf/domain_conf.c | 96 ++++++++++++++++++++--
> > src/qemu/qemu_driver.c | 5 ++
> > src/util/virstoragefile.c | 3 +
> > src/util/virstoragefile.h | 6 ++
> > .../qemuxml2argv-disk-drive-qcow2-cache.xml | 43 ++++++++++
> > .../qemuxml2xmlout-disk-drive-qcow2-cache.xml | 43 ++++++++++
> > tests/qemuxml2xmltest.c | 1 +
> > 9 files changed, 268 insertions(+), 5 deletions(-)
> > create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-disk-drive-qcow2-cache.xml
> > create mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-disk-drive-qcow2-cache.xml
> >
>
> OK - so I had my head in other code during the v4 review comments from
> Peter. So I'll just "restart" that a bit here. If I can summarize the
> comments... There's a concern that we're creating a very specific set of
> parameters for which there isn't great guidance available other than
> going to a source file in the qemu tree and attempting to decipher it.
> Something I did note at one time as a possible issue and why I also
> asked for the "qcow2" subelement. It makes it painfully obvious that
> there was something very specific. I figure seeing a "qcow2" element
> name would fairly easily point out to anyone that specificity.
>
> So, based on what I read in the responses it seems that the purpose of
> the values is to provide a mechanism to "allow" qemu to use a couple of
> different algorithms to perform operations, but qemu wants the user to
> decide whether they are willing to sacrifice one thing over another. If
> you want high IOPS, then you have to sacrifice something else; whereas,
> if you don't care about performance, then you sacrifice something else.
>
> In any case, I think what could be useful is to determine if there is a
> way to "automate" something such that the "dials" would be automatically
> set based on the algorithms. That is - rather than supplying the
> specific values, supply a named attribute that would then perform the
> calculations and set the values, such as "high_performance="yes" or
> "large_capacity=yes". Where you cannot set both, but can set one or the
> other. Or can you set both? Is there value in partially turning a knob?
> If so maybe the attribute is "performance={default, ..., best}" and
> "capacity={default, ..., large}". Then based on the value of the
> attribute, code you add to libvirt would perform the calculations.
While I think that having an user friendly way (not having to inspect
the image to set similar parameters across different VMs) would be
great, boolean parameters will basically translate into some kind of
policy decision we are trying to avoid.
I thought that we could set the cache e.g. in percent of the image it
can cover, but that lacks transparency in regards to consumed memory,
but that's similar to the boolean flags.
While I really don't like meaningless knobs that can change in the
future I currently can't think of anything that would be user friendly
and not step into the "policy" region.
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
