From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ryan Harper Subject: Re: [PATCH v4 0/3] The intro for QEMU disk I/O limits Date: Mon, 1 Aug 2011 15:06:22 -0500 Message-ID: <20110801200622.GL7358@us.ibm.com> References: <1312179955-23536-1-git-send-email-wuzhy@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: kwolf@redhat.com, aliguori@us.ibm.com, stefanha@linux.vnet.ibm.com, kvm@vger.kernel.org, mtosatti@redhat.com, qemu-devel@nongnu.org, zwu.kernel@gmail.com, luowenj@cn.ibm.com, raharper@us.ibm.com To: Zhi Yong Wu Return-path: Content-Disposition: inline In-Reply-To: <1312179955-23536-1-git-send-email-wuzhy@linux.vnet.ibm.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org Sender: qemu-devel-bounces+gceq-qemu-devel=gmane.org@nongnu.org List-Id: kvm.vger.kernel.org * Zhi Yong Wu [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@us.ibm.com From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:37622) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qnylj-0001RP-T6 for qemu-devel@nongnu.org; Mon, 01 Aug 2011 16:07:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qnylj-0007uy-0X for qemu-devel@nongnu.org; Mon, 01 Aug 2011 16:07:19 -0400 Received: from e32.co.us.ibm.com ([32.97.110.150]:33428) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qnyli-0007uh-Ra for qemu-devel@nongnu.org; Mon, 01 Aug 2011 16:07:18 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e32.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p71IvEAH032674 for ; Mon, 1 Aug 2011 12:57:14 -0600 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p71K6wY3044476 for ; Mon, 1 Aug 2011 14:06:59 -0600 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p71K6Xn5015655 for ; Mon, 1 Aug 2011 14:06:36 -0600 Date: Mon, 1 Aug 2011 15:06:22 -0500 From: Ryan Harper Message-ID: <20110801200622.GL7358@us.ibm.com> References: <1312179955-23536-1-git-send-email-wuzhy@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1312179955-23536-1-git-send-email-wuzhy@linux.vnet.ibm.com> Subject: Re: [Qemu-devel] [PATCH v4 0/3] The intro for QEMU disk I/O limits List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Zhi Yong Wu Cc: kwolf@redhat.com, aliguori@us.ibm.com, stefanha@linux.vnet.ibm.com, kvm@vger.kernel.org, mtosatti@redhat.com, qemu-devel@nongnu.org, zwu.kernel@gmail.com, luowenj@cn.ibm.com, raharper@us.ibm.com * Zhi Yong Wu [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@us.ibm.com