Skip to content
Snippets Groups Projects
  • Paolo Bonzini's avatar
    4951967d
    ratelimit: protect with a mutex · 4951967d
    Paolo Bonzini authored
    
    Right now, rate limiting is protected by the AioContext mutex, which is
    taken for example both by the block jobs and by qmp_block_job_set_speed
    (via find_block_job).
    
    We would like to remove the dependency of block layer code on the
    AioContext mutex, since most drivers and the core I/O code are already
    not relying on it.  However, there is no existing lock that can easily
    be taken by both ratelimit_set_speed and ratelimit_calculate_delay,
    especially because the latter might run in coroutine context (and
    therefore under a CoMutex) but the former will not.
    
    Since concurrent calls to ratelimit_calculate_delay are not possible,
    one idea could be to use a seqlock to get a snapshot of slice_ns and
    slice_quota.  But for now keep it simple, and just add a mutex to the
    RateLimit struct; block jobs are generally not performance critical to
    the point of optimizing the clock cycles spent in synchronization.
    
    This also requires the introduction of init/destroy functions, so
    add them to the two users of ratelimit.h.
    
    Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
    4951967d
    History
    ratelimit: protect with a mutex
    Paolo Bonzini authored
    
    Right now, rate limiting is protected by the AioContext mutex, which is
    taken for example both by the block jobs and by qmp_block_job_set_speed
    (via find_block_job).
    
    We would like to remove the dependency of block layer code on the
    AioContext mutex, since most drivers and the core I/O code are already
    not relying on it.  However, there is no existing lock that can easily
    be taken by both ratelimit_set_speed and ratelimit_calculate_delay,
    especially because the latter might run in coroutine context (and
    therefore under a CoMutex) but the former will not.
    
    Since concurrent calls to ratelimit_calculate_delay are not possible,
    one idea could be to use a seqlock to get a snapshot of slice_ns and
    slice_quota.  But for now keep it simple, and just add a mutex to the
    RateLimit struct; block jobs are generally not performance critical to
    the point of optimizing the clock cycles spent in synchronization.
    
    This also requires the introduction of init/destroy functions, so
    add them to the two users of ratelimit.h.
    
    Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
blockjob.c 15.69 KiB