Skip to content
  • Vladimir Sementsov-Ogievskiy's avatar
    7e032df0
    block/block-copy: add ratelimit to block-copy · 7e032df0
    Vladimir Sementsov-Ogievskiy authored
    
    
    We are going to directly use one async block-copy operation for backup
    job, so we need rate limiter.
    
    We want to maintain current backup behavior: only background copying is
    limited and copy-before-write operations only participate in limit
    calculation. Therefore we need one rate limiter for block-copy state
    and boolean flag for block-copy call state for actual limitation.
    
    Note, that we can't just calculate each chunk in limiter after
    successful copying: it will not save us from starting a lot of async
    sub-requests which will exceed limit too much. Instead let's use the
    following scheme on sub-request creation:
    1. If at the moment limit is not exceeded, create the request and
    account it immediately.
    2. If at the moment limit is already exceeded, drop create sub-request
    and handle limit instead (by sleep).
    With this approach we'll never exceed the limit more than by one
    sub-request (which pretty much matches current backup behavior).
    
    Note also, that if there is in-flight block-copy async call,
    block_copy_kick() should be used after set-speed to apply new setup
    faster. For that block_copy_kick() published in this patch.
    
    Signed-off-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
    Reviewed-by: default avatarMax Reitz <mreitz@redhat.com>
    Message-Id: <20210116214705.822267-7-vsementsov@virtuozzo.com>
    Signed-off-by: default avatarMax Reitz <mreitz@redhat.com>
    7e032df0
    block/block-copy: add ratelimit to block-copy
    Vladimir Sementsov-Ogievskiy authored
    
    
    We are going to directly use one async block-copy operation for backup
    job, so we need rate limiter.
    
    We want to maintain current backup behavior: only background copying is
    limited and copy-before-write operations only participate in limit
    calculation. Therefore we need one rate limiter for block-copy state
    and boolean flag for block-copy call state for actual limitation.
    
    Note, that we can't just calculate each chunk in limiter after
    successful copying: it will not save us from starting a lot of async
    sub-requests which will exceed limit too much. Instead let's use the
    following scheme on sub-request creation:
    1. If at the moment limit is not exceeded, create the request and
    account it immediately.
    2. If at the moment limit is already exceeded, drop create sub-request
    and handle limit instead (by sleep).
    With this approach we'll never exceed the limit more than by one
    sub-request (which pretty much matches current backup behavior).
    
    Note also, that if there is in-flight block-copy async call,
    block_copy_kick() should be used after set-speed to apply new setup
    faster. For that block_copy_kick() published in this patch.
    
    Signed-off-by: default avatarVladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
    Reviewed-by: default avatarMax Reitz <mreitz@redhat.com>
    Message-Id: <20210116214705.822267-7-vsementsov@virtuozzo.com>
    Signed-off-by: default avatarMax Reitz <mreitz@redhat.com>
Loading