[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-block] [PATCH 6/7] qemu-iotests: 141: reduce like

From: Sascha Silbe
Subject: Re: [Qemu-devel] [Qemu-block] [PATCH 6/7] qemu-iotests: 141: reduce likelihood of race condition on systems with fast IO
Date: Thu, 07 Apr 2016 22:27:55 +0200
User-agent: Notmuch/0.19+1~g6b3e223 (http://notmuchmail.org) Emacs/24.3.1 (x86_64-pc-linux-gnu)

Dear Max,

Max Reitz <address@hidden> writes:

> On 05.04.2016 11:21, Sascha Silbe wrote:
>> On systems with fast IO, qemu-io may write more than 1 MiB before
>> receiving the block-job-cancel command, causing the test case to fail.
>> 141 is inherently racy, but we can at least reduce the likelihood of the
>> job completing before the cancel command arrives by bumping the size of
>> the data getting written; we'll try 32 MiB for a start.
> Hm, interesting. I tried to prevent this by setting the block jobs'
> speed to 1, which should make it stop after the block job has processed
> the first block of data.

Hmm, seems like I didn't quite understand the way the test works

@Kevin: Please do NOT queue this patch.

@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

Softwareentwicklung Sascha Silbe, Niederhofenstra├če 5/1, 71229 Leonberg
USt-IdNr. DE281696641

reply via email to

[Prev in Thread] Current Thread [Next in Thread]