qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH 2/4] block: immediately cancel oversized read/wr


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 2/4] block: immediately cancel oversized read/write requests
Date: Mon, 08 Sep 2014 18:29:58 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0

Il 08/09/2014 18:18, Peter Lieven ha scritto:
>> > When copying data, gparted will try using very large I/O sizes.  Of
>> > course if something breaks it will just use a smaller size, but it would
>> > make performance worse.
>> > 
>> > I tried now (with local storage, not virtual---but with such large block
>> > sizes it's disk bound anyway, one request can take 0.1 seconds to
>> > execute) and a 2 MB block size is 20% slower than 16 MB block size on
>> > your usual 3.5" rotational SATA disk.
>> > 
> can you share with what command exactly you ran these tests?
> 
> i tried myself and found that without multiwrite_merge i was not able to 
> create a request bigger than 0xffff sectors from inside linux.

On a different machine:

$ time dd if=/dev/zero of=test bs=16777216 count=30 oflag=direct
real    0m13.497s
user    0m0.001s
sys     0m0.541s

$ time dd if=/dev/zero of=test2 bs=1048576 count=480 oflag=direct
real    0m15.835s
user    0m0.005s
sys     0m0.770s

The bigger block size is 17% faster; for disk-to-disk copy:

$ time dd if=test of=test3 bs=16777216 count=30 iflag=direct oflag=direct
real    0m26.075s
user    0m0.001s
sys     0m0.678s

$ time dd if=test2 of=test4 bs=1048576 count=480 iflag=direct oflag=direct
real    0m45.210s
user    0m0.005s
sys     0m1.145s

The bigger block size is 73% faster.

Paolo



reply via email to

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