From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42544) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aoVZN-0001Hb-Tw for qemu-devel@nongnu.org; Fri, 08 Apr 2016 08:31:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aoVZM-0005LQ-Vu for qemu-devel@nongnu.org; Fri, 08 Apr 2016 08:31:25 -0400 Date: Fri, 8 Apr 2016 14:31:15 +0200 From: Kevin Wolf Message-ID: <20160408123115.GH4700@noname.redhat.com> References: <1459848109-29756-1-git-send-email-silbe@linux.vnet.ibm.com> <1459848109-29756-7-git-send-email-silbe@linux.vnet.ibm.com> <57053631.5010009@redhat.com> <87shyxjh9w.fsf@oc4731375738.ibm.com> <87pou0jon2.fsf@oc4731375738.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87pou0jon2.fsf@oc4731375738.ibm.com> Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 6/7] qemu-iotests: 141: reduce likelihood of race condition on systems with fast IO List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Sascha Silbe Cc: Max Reitz , qemu-devel@nongnu.org, qemu-block@nongnu.org, Tu Bo Am 08.04.2016 um 14:01 hat Sascha Silbe geschrieben: > Dear Max, > > Sascha Silbe writes: > > > @Max: From a cursory glance at the code, maybe your 1 *byte* per second > > rate limit is being rounded down to 0 *blocks* per second, with 0 > > meaning no limit? See e.g. mirror_set_speed(). Though I must admit I > > don't understand how speed=0 translates to unlimited (like > > qapi/block-core.json:block-job-set-speed says). My understanding of > > ratelimit_calculate_delay() is that speed=0 means "1 quantum per time > > slice", with time slice usually being 100ms; not sure about the > > quantum. > > I think I've understood the issue now. > > The backup, commit, mirror and stream actions operate in on full chunks, > with chunk size depending on the action and backing device. For > e.g. commit that means it always bursts at least 0.5MiB; that's where > the value the reference output comes from. > > ratelimit_calculate_delay() lets through at least one burst per time > slice. This means the minimum rate is chunk size per time slice (always > 100ms). So for commit and stream one will always get at least 5 MiB/s. A > surprisingly large value for something specified in bytes per second, > BTW. (I.e. it should probably be documented in qmp-commands.hx if it > stays this way). > > On a busy or slow host, it may take the shell longer than the time slice > of 100ms to send the cancel command to qemu. When that happens, > additional chunks will get written before the job gets cancelled. That's > why I sometimes see 1 or even 1.5 MiB as offset, especially when running > CPU intensive workloads in parallel. > > The best approach probably would be to fix up the rate limit code to > delay for multiple time slices if necessary. We should get rid of the > artificial BDRV_SECTOR_SIZE granularity at the same time, always using > bytes as the quantum unit. In the 2.7 time frame we might actually be able to reuse the normal I/O throttling code for block jobs as the jobs will be using their own BlockBackend and can therefore set their own throttling limits. Kevin