qemu-block
[Top][All Lists]
Advanced

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

Re: [Qemu-block] [PATCH v11 0/9] Take the image size into account when a


From: Kevin Wolf
Subject: Re: [Qemu-block] [PATCH v11 0/9] Take the image size into account when allocating the L2 cache
Date: Wed, 26 Sep 2018 12:48:18 +0200
User-agent: Mutt/1.9.1 (2017-09-22)

Am 25.09.2018 um 00:53 hat Leonid Bloch geschrieben:
> This series makes the qcow2 L2 cache assignment aware of the image size,
> with the intention for it to cover the entire image. The importance of
> this change is in noticeable performance improvement, especially with
> heavy random I/O. The memory overhead is not big in most cases, as only
> 1 MB of cache for every 8 GB of image size is used. For cases with very
> large images and/or small cluster sizes, or systems with limited RAM
> resources, there is an upper limit on the default L2 cache: 32 MB for
> Linux systems, and 8 MB for non-Linux systems (the difference is caused
> by the fact that it is currently impossible to perform scheduled cache
> cleaning on non-Linux systems). To modify this upper limit one can use
> the already existing 'l2-cache-size' and 'cache-size' options. Moreover,
> this fixes the behavior of 'l2-cache-size', as it was documented as the
> *maximum* L2 cache size, but in practice behaved as the absolute size.
> 
> To compensate the memory overhead which may (but not necesarily will) be
> increased following this behavior, the default cache-clean-interval is set
> to 10 minutes by default (was disabled by default before).
> 
> The L2 cache is also resized accordingly, by default, if the image is
> resized.
> 
> Additionally, few minor changes are made (refactoring and documentation
> fixes).

Patches 1-6 and 8-9:
Reviewed-by: Kevin Wolf <address@hidden>

By the way, Berto: While reviewing this, I noticed that we don't make
use of the l2-cache-entry-size feature yet by default. I think you said
you wanted to do some more tests to find a good default (intuitively,
I'd expect it around MIN(cluster size, 64k), maybe 128k, but of course
this needs some benchmarking). Obviously, that's for a separate series,
though.

Kevin



reply via email to

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