From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40672) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bZfA0-0004T7-AH for qemu-devel@nongnu.org; Tue, 16 Aug 2016 10:16:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bZf9v-0003kX-8t for qemu-devel@nongnu.org; Tue, 16 Aug 2016 10:16:07 -0400 References: <1470748523-13856-1-git-send-email-vsementsov@virtuozzo.com> From: Pavel Butsykin Message-ID: <57B2FC95.7040809@virtuozzo.com> Date: Tue, 16 Aug 2016 14:44:21 +0300 MIME-Version: 1.0 In-Reply-To: <1470748523-13856-1-git-send-email-vsementsov@virtuozzo.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2] iotest 055: refactor and speed up List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladimir Sementsov-Ogievskiy , qemu-block@nongnu.org, qemu-devel@nongnu.org Cc: kwolf@redhat.com, mreitz@redhat.com, stefanha@redhat.com, den@openvz.org, famz@redhat.com, jsnow@redhat.com On 09.08.2016 16:15, Vladimir Sementsov-Ogievskiy wrote: > Source disk is created and filled with test data before each test case. > Instead initialize it once for the whole unit. > > Test disk filling patterns are merged into one pattern. > > Also TestSetSpeed used different image_len for source and target (by > mistake) - this is automatically fixed here. > > Signed-off-by: Vladimir Sementsov-Ogievskiy > --- > > v2: rebase on block-next, as compression test pattern differs, merge patterns. > > Need review from Pavel, is new merged disk filling pattern ok for you? > > Also, removed from commit message performance measurements. On block-next this test > is too long for other reasons, so for qcow speed is not such significant: for qcow2 > I have 7min:33s -> 6min:45s. > > > tests/qemu-iotests/055 | 52 +++++++++++++++++--------------------------------- > 1 file changed, 18 insertions(+), 34 deletions(-) > Reviewed-by: Pavel Butsykin But unfortunately, here the main slowing factor is vmdk compression.