Am 05.02.2016 um 11:59 hat Alberto Garcia geschrieben: > Hello everyone, > > the current throttling code in QEMU allows limiting the I/O rate on > block devices. Limits can be set in operations per second (IOPS) or > bytes per second, allowing separate limits for read and write > operations on both cases. > > In its basic usage the user can set a limit of, say, 100 IOPS on a > block device passing this option to -drive: > > throttling.iops-total=100 > > In addition to that, QEMU can also allow the user to do I/O bursts > exceeding that limit up to a configurable rate: > > throttling.iops-total=100,throttling.iops-total-max=2000 > > With this, the user can do a burst of 2000 IOPS before they're > throttled down to 100 IOPS. Then, after a sufficiently long period of > unused I/O they will be able to do a burst again. > > This patch series introduces the possibility to do bursts for longer > period of times. A new setting called throttling.iops-total-max-length > is used to define for how long bursts can be sustained. > > So adding throttling.iops-total-max-length=60 to the previous > configuration allows the user to do I/O at a rate of 2000 IOPS for 1 > minute before going down to the base rate of 100 IOPS. > > This is essentially the same as described in this AWS blog post: > > https://aws.amazon.com/blogs/aws/new-ssd-backed-elastic-block-storage/ > > As described in the article, a use case for this feature is to allow > better performance when booting the OS or restarting a service while > keeping the average I/O limits lower the rest of the time. > > Comments: > > - There are 6 different settings for setting I/O limits: iops-total, > iops-read, iops-write, bps-total, bps-read, bps-write. This series > adds one new setting to set the length for each one of those. > > I don't know if there's a good use case that requires such > fine-grained control. It's of course also possible to make it > simpler and add just one 'burst-length' setting that would apply > for all cases, but the current solution is IMHO simple enough and > consistent with the current API, and if we need to extend it later > the result is probably going to be ugly. > > - With this series we set "a maximum of X operations/second for a > period of T seconds". If would also be possible to make it "a > maximum of X operations/second up to a total of Y operations". It > would be equivalent (Y = X * T) but I thought the current proposal > makes a more clear API. > > And I think that's all.
Congratulations, you found the unmaintained spot in the block layer! :-) Anyway, the cover letter makes sense to me. And thanks for this great writeup! Can we turn it into documentation? Throttling seems to be quite underdocumented, and your explanation above let me understand for the first time what these *-max options actually were. I'll have to see whether I can review the meat of this series next week, but for now: Patches 1-7: Reviewed-by: Kevin Wolf <kw...@redhat.com>
