From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:48511) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIU9Z-0007Du-3P for qemu-devel@nongnu.org; Wed, 20 Mar 2013 21:18:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIU9W-0007K9-5l for qemu-devel@nongnu.org; Wed, 20 Mar 2013 21:18:49 -0400 Received: from e31.co.us.ibm.com ([32.97.110.149]:34918) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIU9W-0007Jx-03 for qemu-devel@nongnu.org; Wed, 20 Mar 2013 21:18:46 -0400 Received: from /spool/local by e31.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 20 Mar 2013 19:18:44 -0600 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id 84F521FF0039 for ; Wed, 20 Mar 2013 19:13:45 -0600 (MDT) Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r2L1IeFF100488 for ; Wed, 20 Mar 2013 19:18:40 -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 r2L1IcJC027744 for ; Wed, 20 Mar 2013 19:18:40 -0600 From: Zhi Yong Wu Date: Thu, 21 Mar 2013 09:18:27 +0800 In-Reply-To: <20130320151203.GA3584@stefanha-thinkpad.muc.redhat.com> References: <1363770734-30970-1-git-send-email-benoit@irqsave.net> <1363770734-30970-2-git-send-email-benoit@irqsave.net> <20130320132924.GB14441@stefanha-thinkpad.muc.redhat.com> <20130320142842.GA2389@stefanha-thinkpad.muc.redhat.com> <20130320145633.GA1473@irqsave.net> <20130320151203.GA3584@stefanha-thinkpad.muc.redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Message-ID: <1363828709.32706.86.camel@f15> Mime-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] block: fix bdrv_exceed_iops_limits wait computation Reply-To: wuzhy@linux.vnet.ibm.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: =?ISO-8859-1?Q?Beno=EEt?= Canet , Stefan Hajnoczi , qemu-devel@nongnu.org, kwolf@redhat.com On Wed, 2013-03-20 at 16:12 +0100, Stefan Hajnoczi wrote: > On Wed, Mar 20, 2013 at 03:56:33PM +0100, Benoît Canet wrote: > > > But I don't understand why bs->slice_time is modified instead of keeping > > > it constant at 100 ms: > > > > > > bs->slice_time = wait_time * BLOCK_IO_SLICE_TIME * 10; > > > bs->slice_end += bs->slice_time - 3 * BLOCK_IO_SLICE_TIME; > > > if (wait) { > > > *wait = wait_time * BLOCK_IO_SLICE_TIME * 10; > > > } > > > > In bdrv_exceed_bps_limits there is an equivalent to this with a comment. > > > > --------- > > /* When the I/O rate at runtime exceeds the limits, > > * bs->slice_end need to be extended in order that the current statistic > > * info can be kept until the timer fire, so it is increased and tuned > > * based on the result of experiment. > > */ > > bs->slice_time = wait_time * BLOCK_IO_SLICE_TIME * 10; > > bs->slice_end += bs->slice_time - 3 * BLOCK_IO_SLICE_TIME; > > if (wait) { > > *wait = wait_time * BLOCK_IO_SLICE_TIME * 10; > > } > > ---------- > > The comment explains why slice_end needs to be extended, but not why > bs->slice_time should be changed (except that it was tuned as the result > of an experiment). > > Zhi Yong: Do you remember a reason for modifying bs->slice_time? Stefan, In some case that the bare I/O speed is very fast on physical machine, when I/O speed is limited to be one lower value, I/O need to wait for one relative longer time(i.e. wait_time). You know, wait_time should be smaller than slice_time, if slice_time is constant, wait_time may not be its expected value, so the throttling function will not work well. For example, bare I/O speed is 100MB/s, I/O throttling speed is 1MB/s, slice_time is constant, and set to 50ms(a assumed value) or smaller, If current I/O can be throttled to 1MB/s, its wait_time is expected to 100ms(a assumed value), and is more bigger than current slice_time, I/O throttling function will not throttle actual I/O speed well. In the case, slice_time need to be adjusted to one more suitable value which depends on wait_time. In some other case that the bare I/O speed is very slow and I/O throttling speed is fast, slice_time also need to be adjusted dynamically based on wait_time. If i remember correctly, it's the reason. > > Stefan > -- Regards, Zhi Yong Wu