Re: [PATCH v3 18/18] blockjob: allow finer bandwidth tuning for set speed

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

 



On 08/31/14 06:02, Eric Blake wrote:
> We stupidly modeled block job bandwidth after migration
> bandwidth, which in turn was an 'unsigned long' and therefore
> subject to 32-bit vs. 64-bit interpretations.  To work around
> the fact that 10-gigabit interfaces are possible but don't fit
> within 32 bits, the original interface took the number scaled
> as MiB/sec.  But this scaling is rather coarse, and it might
> be nice to tune bandwidth finer than in megabyte chunks.
> 
> Several of the block job calls that can set speed are fed
> through a common interface, so it was easier to adjust them all
> at once.  Note that there is intentionally no flag for the new
> virDomainBlockCopy; there, since the API already uses a 64-bit
> type always, instead of a possible 32-bit type, and is brand
> new, it was easier to just avoid scaling issues.  As with the
> previous patch that adjusted the query side, omitting the new
> flag preserves old behavior, and the documentation now mentions
> limits of what happens when a 32-bit machine is on either client
> or server side.
> 
> * include/libvirt/libvirt.h.in (virDomainBlockJobSetSpeedFlags)
> (virDomainBlockPullFlags)
> (VIR_DOMAIN_BLOCK_REBASE_BANDWIDTH_BYTES)
> (VIR_DOMAIN_BLOCK_COMMIT_BANDWIDTH_BYTES): New enums.
> * src/libvirt.c (virDomainBlockJobSetSpeed, virDomainBlockPull)
> (virDomainBlockRebase, virDomainBlockCommit): Document them.
> * src/qemu/qemu_driver.c (qemuDomainBlockJobSetSpeed)
> (qemuDomainBlockPull, qemuDomainBlockRebase)
> (qemuDomainBlockCommit, qemuDomainBlockJobImpl): Support new flag.
> 
> Signed-off-by: Eric Blake <eblake@xxxxxxxxxx>
> ---
>  include/libvirt/libvirt.h.in | 31 +++++++++++++----
>  src/libvirt.c                | 83 +++++++++++++++++++++++++++++++-------------
>  src/qemu/qemu_driver.c       | 61 +++++++++++++++++++-------------
>  3 files changed, 118 insertions(+), 57 deletions(-)
> 

ACK, the better granularity may help today, while we are able to keep
the huge range for future expansion.

Peter


Attachment: signature.asc
Description: OpenPGP digital signature

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]