From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: [PATCH v2 1/1] The codes V2 for QEMU disk I/O limits. Date: Thu, 28 Jul 2011 11:42:11 -0300 Message-ID: <20110728144211.GA17754@amt.cnet> References: <1311670746-20498-1-git-send-email-wuzhy@linux.vnet.ibm.com> <1311670746-20498-2-git-send-email-wuzhy@linux.vnet.ibm.com> <20110726192618.GA8126@amt.cnet> <20110727154913.GA6334@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Zhi Yong Wu , qemu-devel@nongnu.org, kvm@vger.kernel.org, aliguori@us.ibm.com, stefanha@linux.vnet.ibm.com, ryanh@us.ibm.com, kwolf@redhat.com, vgoyal@redhat.com To: Zhi Yong Wu Return-path: Received: from mx1.redhat.com ([209.132.183.28]:20132 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754482Ab1G1O6C (ORCPT ); Thu, 28 Jul 2011 10:58:02 -0400 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Thu, Jul 28, 2011 at 12:24:48PM +0800, Zhi Yong Wu wrote: > On Wed, Jul 27, 2011 at 11:49 PM, Marcelo Tosatti wrote: > > On Wed, Jul 27, 2011 at 06:17:15PM +0800, Zhi Yong Wu wrote: > >> >> + =A0 =A0 =A0 =A0wait_time =3D 1; > >> >> + =A0 =A0} > >> >> + > >> >> + =A0 =A0wait_time =3D wait_time + (slice_time - elapsed_time); > >> >> + =A0 =A0if (wait) { > >> >> + =A0 =A0 =A0 =A0*wait =3D wait_time * BLOCK_IO_SLICE_TIME * 10= + 1; > >> >> + =A0 =A0} > >> > > >> > The guest can keep submitting requests where "wait_time =3D 1" a= bove, > >> > and the timer will be rearmed continuously in the future. > > > > This is wrong. > > > >> =A0Can't you > >> > simply arm the timer to the next slice start? _Some_ data must b= e > >> > transfered by then, anyway (and nothing can be transfered earlie= r than > >> > that). > > > > This is valid. > > > >> Sorry, i have got what you mean. Can you elaborate in more detail? > > > > Sorry, the bug i mentioned about timer being rearmed does not exist= =2E > > > > But arming the timer for the last request as its done is confusing/= unnecessary. > > > > The timer processes queued requests, but the timer is armed accordi= ngly > > to the last queued request in the slice. For example, if a request = is > > submitted 1ms before the slice ends, the timer is armed 100ms + > > (slice_time - elapsed_time) in the future. >=20 > If the timer is simply amred to the next slice start, this timer will > be a periodic timer, either the I/O rate can not be throttled under > the limits, or the enqueued request can be delayed to handled, this > will lower I/O rate seriously than the limits. Yes, periodic but disarmed when there is no queueing. I don't understan= d your point about low I/O rate. > Maybe the slice time should be variable with current I/O rate. What d= o > you think of it? Not sure if its necessary. The slice should be small to avoid excessive work on timer context, but the advantage of increasing the slice is very small if any. BTW, 10ms seems a better default than 100ms.