On 01/26/2018 09:00 AM, Alberto Garcia wrote: > Now that the code is ready to handle L2 slices we can finally add an > option to allow configuring their size. > > An L2 slice is the portion of an L2 table that is read by the qcow2 > cache. Until now the cache was always reading full L2 tables, and > since the L2 table size is equal to the cluster size this was not very > efficient with large clusters. Here's a more detailed explanation of > why it makes sense to have smaller cache entries in order to load L2 > data: > > https://lists.gnu.org/archive/html/qemu-block/2017-09/msg00635.html > > This patch introduces a new command-line option to the qcow2 driver > named l2-cache-entry-size (cf. l2-cache-size). The cache entry size > has the same restrictions as the cluster size: it must be a power of > two and it has the same range of allowed values, with the additional > requirement that it must not be larger than the cluster size. > > The L2 cache entry size (L2 slice size) remains equal to the cluster > size for now by default, so this feature must be explicitly enabled. > Although my tests show that 4KB slices consistently improve > performance and give the best results, let's wait and make more tests > with different cluster sizes before deciding on an optimal default. > > Now that the cache entry size is not necessarily equal to the cluster > size we need to reflect that in the MIN_L2_CACHE_SIZE documentation. > That minimum value is a requirement of the COW algorithm: we need to > read two L2 slices (and not two L2 tables) in order to do COW, see > l2_allocate() for the actual code. > > Signed-off-by: Alberto Garcia <be...@igalia.com> > --- Reviewed-by: Eric Blake <ebl...@redhat.com>
-- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature