From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37943) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aoVGQ-000362-Hh for qemu-devel@nongnu.org; Fri, 08 Apr 2016 08:11:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aoVGK-0000QZ-Pq for qemu-devel@nongnu.org; Fri, 08 Apr 2016 08:11:50 -0400 Received: from e06smtp12.uk.ibm.com ([195.75.94.108]:59628) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aoVGK-0000QJ-Hn for qemu-devel@nongnu.org; Fri, 08 Apr 2016 08:11:44 -0400 Received: from localhost by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 8 Apr 2016 13:11:41 +0100 From: Sascha Silbe In-Reply-To: <87shyxjh9w.fsf@oc4731375738.ibm.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> Date: Fri, 08 Apr 2016 14:01:05 +0200 Message-ID: <87pou0jon2.fsf@oc4731375738.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Max Reitz , qemu-devel@nongnu.org, qemu-block@nongnu.org, Kevin Wolf Cc: Tu Bo 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=3D0 translates to unlimited (like > qapi/block-core.json:block-job-set-speed says). My understanding of > ratelimit_calculate_delay() is that speed=3D0 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. Sascha --=20 Softwareentwicklung Sascha Silbe, Niederhofenstra=C3=9Fe 5/1, 71229 Leonberg https://se-silbe.de/ USt-IdNr. DE281696641