[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH] qcow2: Optimize L2 table cache size based on im

From: Frank Myhr
Subject: Re: [Qemu-block] [PATCH] qcow2: Optimize L2 table cache size based on image and cluster sizes
Date: Wed, 19 Oct 2016 12:34:43 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0

On 10/18/2016 11:25 AM, Alberto Garcia wrote:
> On Fri 07 Oct 2016 03:58:29 PM CEST, Ed Swierk wrote:
>> Same here, using libvirt. l2-cache-size=max would be ideal. Or if
>> there were a cache-coverage-size option that takes an absolute number,
>> libvirt could set it to the image size.
> I can see the benefit of both approaches: setting the disk size covered
> by the cache or setting a percentage, I personally like a bit more the
> former but it wouldn't provide a way to say "create the largest cache
> needed for this disk".

I prefer percentage (or just 'max') because it eliminates a source of
performance problems when increasing the size of a VM's disk(s). Take the case
of a VM doing heavy random I/O on a 10GB disk. Admin1 initially sets
l2-cache-size=1.25M or l2-cache-coverage-size=10G. At some point the disk fills
up as they always do, and admin2 (or admin1 on a bad day) increases its size to
20GB: problem solved. Except admin2 forgot to also double l2-cache-size or
l2-cache-coverage-size. So performance with larger drive takes a nosedive (~*6X*
worse in your worst-case benchmark) until some admin figures it out.


Sure, admins shouldn't make this mistake. But guaranteed they (cough, I) will.
Using percentage makes this mistake impossible.

> Would 'l2-cache-coverage-size' work for everyone? It would simply take
> the disk size (16G, 1T, etc) and it would conflict with l2-cache-size.

The above said, l2-cache-coverage-size would work for me if libvirt could set
it. Or if it defaulted to entire image size, eliminating the need for libvirt to
set it, and making impossible the admin mistake above.

> Do we need something similar for the refcount cache?

I don't know. AFAICT the current default refcount behavior is fine. But might be
good to keep l2 and refcount options symmetrical.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]