qemu-block
[Top][All Lists]
Advanced

[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: Max Reitz
Subject: Re: [Qemu-block] [PATCH] qcow2: Optimize L2 table cache size based on image and cluster sizes
Date: Tue, 4 Oct 2016 17:51:26 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0

On 04.10.2016 17:36, Ed Swierk wrote:
> On Tue, Oct 4, 2016 at 7:31 AM, Alberto Garcia <address@hidden> wrote:
>> That might be a lot of memory if the image is big. 1 TB qcow2 image ==
>> 128 MB L2 cache.
>>
>> See https://bugzilla.redhat.com/show_bug.cgi?id=1377735#c2
>>
>> If we want to add this feature, I think I'd rather make it explicit.
> 
> I agree explicit is generally better than automagical, but unlike say
> the VM RAM size, the qcow L2 table cache is an implementation detail
> no user should be expected to know exists, let alone needs tweaking
> according to a specific formula to avoid an arbitrary performance
> cliff.

I think a user can be expected to know it when they really want optimal
performance for huge workloads.

> At least giving users a way to skip the math would be an improvement.
> Would you be okay with an explicitly-set option like
> l2_cache_size=auto or =max that optimizes for performance at the
> expense of memory?

That (cache-size=max) is actually something Stefan Hajnoczi has proposed
at KVM Forum 2015.

I agree that implementing the formula in qemu's qcow2 driver itself
makes sense and will help users; however, I do think it is appropriate
to expect the user to pass cache-size=max if they need it.

We shouldn't fix this lack of knowledge by making cache-size=max the
default but by documenting it properly (although I'm yet unsure where to
do that, other than in some blog...). Also, we have the
cache-clean-interval option which makes the qcow2 driver automatically
clean up unused entries in the metadata caches, which would be very
useful for cache-size=max; we thus shouldn't forget to mention that in
the documentation as well.

Max

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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