Skip to content
  • Alberto Garcia's avatar
    1221fe6f
    qcow2: Allow configuring the L2 slice size · 1221fe6f
    Alberto Garcia authored
    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: default avatarAlberto Garcia <berto@igalia.com>
    Reviewed-by: default avatarEric Blake <eblake@redhat.com>
    Reviewed-by: default avatarMax Reitz <mreitz@redhat.com>
    Message-id: c73e5611ff4a9ec5d20de68a6c289553a13d2354.1517840877.git.berto@igalia.com
    Signed-off-by: default avatarMax Reitz <mreitz@redhat.com>
    1221fe6f
    qcow2: Allow configuring the L2 slice size
    Alberto Garcia authored
    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: default avatarAlberto Garcia <berto@igalia.com>
    Reviewed-by: default avatarEric Blake <eblake@redhat.com>
    Reviewed-by: default avatarMax Reitz <mreitz@redhat.com>
    Message-id: c73e5611ff4a9ec5d20de68a6c289553a13d2354.1517840877.git.berto@igalia.com
    Signed-off-by: default avatarMax Reitz <mreitz@redhat.com>
Loading