* Zhi Yong Wu <wuzhy@xxxxxxxxxxxxxxxxxx> [2011-08-01 01:30]: > The main goal of the patch is to effectively cap the disk I/O speed or counts of one single VM.It is only one draft, so it unavoidably has some drawbacks, if you catch them, please let me know. > > The patch will mainly introduce one block I/O throttling algorithm, one timer and one block queue for each I/O limits enabled drive. > > When a block request is coming in, the throttling algorithm will check if its I/O rate or counts exceed the limits; if yes, then it will enqueue to the block queue; The timer will handle the I/O requests in it. > > Some available features follow as below: > (1) global bps limit. > -drive bps=xxx in bytes/s > (2) only read bps limit > -drive bps_rd=xxx in bytes/s > (3) only write bps limit > -drive bps_wr=xxx in bytes/s > (4) global iops limit > -drive iops=xxx in ios/s > (5) only read iops limit > -drive iops_rd=xxx in ios/s > (6) only write iops limit > -drive iops_wr=xxx in ios/s > (7) the combination of some limits. > -drive bps=xxx,iops=xxx > > Known Limitations: > (1) #1 can not coexist with #2, #3 > (2) #4 can not coexist with #5, #6 > (3) When bps/iops limits are specified to a small value such as 511 bytes/s, this VM will hang up. We are considering how to handle this senario. > > > Zhi Yong Wu (3): > v4: fix memory leaking based on ryan's feedback. It looks like the leak has been fixed, but I think we need to rework how the blk-queue is using the AIOPool. I'll reply to that patch. -- Ryan Harper Software Engineer; Linux Technology Center IBM Corp., Austin, Tx ryanh@xxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
