All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sascha Silbe <silbe@linux.vnet.ibm.com>
To: Max Reitz <mreitz@redhat.com>,
	qemu-devel@nongnu.org, qemu-block@nongnu.org,
	Kevin Wolf <kwolf@redhat.com>
Cc: Tu Bo <tubo@linux.vnet.ibm.com>
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 6/7] qemu-iotests: 141: reduce likelihood of race condition on systems with fast IO
Date: Fri, 08 Apr 2016 14:01:05 +0200	[thread overview]
Message-ID: <87pou0jon2.fsf@oc4731375738.ibm.com> (raw)
In-Reply-To: <87shyxjh9w.fsf@oc4731375738.ibm.com>

Dear Max,

Sascha Silbe <silbe@linux.vnet.ibm.com> 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.

Sascha
-- 
Softwareentwicklung Sascha Silbe, Niederhofenstraße 5/1, 71229 Leonberg
https://se-silbe.de/
USt-IdNr. DE281696641

  parent reply	other threads:[~2016-04-08 12:11 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-05  9:21 [Qemu-devel] [PATCH 0/7] next round of qemu-iotests fixes Sascha Silbe
2016-04-05  9:21 ` [Qemu-devel] [PATCH 1/7] qemu-iotests: check: don't place files with predictable names in /tmp Sascha Silbe
2016-04-06 15:36   ` [Qemu-devel] [Qemu-block] " Max Reitz
2016-04-07 19:54     ` Sascha Silbe
2016-04-05  9:21 ` [Qemu-devel] [PATCH 2/7] qemu-iotests: fix 051 on non-PC architectures Sascha Silbe
2016-04-06 15:43   ` [Qemu-devel] [Qemu-block] " Max Reitz
2016-04-05  9:21 ` [Qemu-devel] [PATCH 3/7] qemu-iotests: iotests.VM: remove qtest socket on error Sascha Silbe
2016-04-06 15:55   ` [Qemu-devel] [Qemu-block] " Max Reitz
2016-04-07 19:58     ` Sascha Silbe
2016-04-05  9:21 ` [Qemu-devel] [PATCH 4/7] qemu-iotests: 148: properly skip test if quorum support is missing Sascha Silbe
2016-04-06 16:04   ` [Qemu-devel] [Qemu-block] " Max Reitz
2016-04-05  9:21 ` [Qemu-devel] [PATCH 5/7] qemu-iotests: 068: don't require KVM Sascha Silbe
2016-04-06 16:12   ` [Qemu-devel] [Qemu-block] " Max Reitz
2016-04-05  9:21 ` [Qemu-devel] [PATCH 6/7] qemu-iotests: 141: reduce likelihood of race condition on systems with fast IO Sascha Silbe
2016-04-06 16:15   ` [Qemu-devel] [Qemu-block] " Max Reitz
2016-04-06 16:30     ` Kevin Wolf
2016-04-07 20:27     ` Sascha Silbe
2016-04-08 11:11       ` Kevin Wolf
2016-04-08 12:01       ` Sascha Silbe [this message]
2016-04-08 12:31         ` Kevin Wolf
2016-04-08 13:46           ` Sascha Silbe
2016-04-05  9:21 ` [Qemu-devel] [PATCH 7/7] qemu-iotests: iotests.py: get rid of __all__ Sascha Silbe
2016-04-06 16:18   ` [Qemu-devel] [Qemu-block] " Max Reitz
2016-04-08 14:49 ` [Qemu-devel] [Qemu-block] [PATCH 0/7] next round of qemu-iotests fixes Max Reitz
2016-04-08 17:17   ` Sascha Silbe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pou0jon2.fsf@oc4731375738.ibm.com \
    --to=silbe@linux.vnet.ibm.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=tubo@linux.vnet.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.