From: "Pádraig Brady" <P@draigBrady.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Wu Fengguang <wfg@linux.intel.com>,
Herbert Poetzl <herbert@13thfloor.at>,
Andrew Morton <akpm@linux-foundation.org>,
LKML <linux-kernel@vger.kernel.org>, Jens Axboe <axboe@kernel.dk>,
Tejun Heo <tj@kernel.org>
Subject: Re: Bad SSD performance with recent kernels
Date: Sun, 29 Jan 2012 15:52:06 +0000 [thread overview]
Message-ID: <4F256B26.3060309@draigBrady.com> (raw)
In-Reply-To: <1327842831.2718.2.camel@edumazet-laptop>
On 01/29/2012 01:13 PM, Eric Dumazet wrote:
> Le dimanche 29 janvier 2012 à 19:16 +0800, Wu Fengguang a écrit :
>
>
>> Note that as long as buffered read(2) is used, it makes almost no
>> difference (well, at least for now) to do "dd bs=128k" or "dd bs=2MB":
>> the 128kb readahead size will be used underneath to submit read IO.
>>
>
> Hmm...
>
> # echo 3 >/proc/sys/vm/drop_caches ;dd if=/dev/sda of=/dev/null bs=128k count=32768
> 32768+0 enregistrements lus
> 32768+0 enregistrements écrits
> 4294967296 octets (4,3 GB) copiés, 20,7718 s, 207 MB/s
>
>
> # echo 3 >/proc/sys/vm/drop_caches ;dd if=/dev/sda of=/dev/null bs=2M count=2048
> 2048+0 enregistrements lus
> 2048+0 enregistrements écrits
> 4294967296 octets (4,3 GB) copiés, 27,7824 s, 155 MB/s
Same here on 2.6.40.4-5.fc15.x86_64
Note the SSD is rated for 500MB/s but is on a SATA II port,
and so limited by that. So the 128k result below is
close to the limit on this system.
Hmm, I previously tested this SSD with kernel-2.6.38.6-26.rc1.fc15.src.rpm
and got 270MB/s. Testing now gives variable and lower results:
# echo 3 >/proc/sys/vm/drop_caches; hdparm -tT /dev/sdb
/dev/sdb:
Timing cached reads: 8388 MB in 2.00 seconds = 4200.73 MB/sec
Timing buffered disk reads: 550 MB in 3.00 seconds = 183.19 MB/sec
# echo 3 >/proc/sys/vm/drop_caches; hdparm -tT /dev/sdb
/dev/sdb:
Timing cached reads: 8260 MB in 2.00 seconds = 4134.30 MB/sec
Timing buffered disk reads: 680 MB in 3.00 seconds = 226.63 MB/sec
# echo 3 >/proc/sys/vm/drop_caches; hdparm -tT /dev/sdb
/dev/sdb:
Timing cached reads: 8426 MB in 2.00 seconds = 4217.87 MB/sec
Timing buffered disk reads: 588 MB in 3.00 seconds = 195.96 MB/sec
Anyway testing different block sizes with dd:
# echo 3 >/proc/sys/vm/drop_caches; timeout -sINT 5 dd if=/dev/sdb of=/dev/null bs=2M
966787072 bytes (967 MB) copied, 5.00525 s, 193 MB/s
# echo 3 >/proc/sys/vm/drop_caches; timeout -sINT 5 dd if=/dev/sdb of=/dev/null bs=128k
1246494720 bytes (1.2 GB) copied, 4.99563 s, 250 MB/s
On a probably unrelated note, I've always noticed dd getting slower,
independent of disks, when the buffer size increases beyond 2M.
for i in $(seq 0 15); do
size=$((16*1024**3)) #ensure this is big enough
bs=$((1024*2**$i))
printf "%8s=" $bs
dd bs=$bs if=/dev/zero of=/dev/null count=$(($size/$bs)) 2>&1 |
sed -n 's/.* \([0-9.]* [GM]B\/s\)/\1/p'
done
1024=1.4 GB/s
2048=2.6 GB/s
4096=4.5 GB/s
8192=6.7 GB/s
16384=8.8 GB/s
32768=9.4 GB/s
65536=10.8 GB/s
131072=11.5 GB/s
262144=11.5 GB/s
524288=11.3 GB/s
1048576=11.3 GB/s
2097152=10.6 GB/s
4194304=6.5 GB/s
8388608=5.9 GB/s
16777216=6.6 GB/s
33554432=6.6 GB/s
cheers,
Pádraig.
next prev parent reply other threads:[~2012-01-29 16:01 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-27 6:00 Bad SSD performance with recent kernels Herbert Poetzl
2012-01-27 6:44 ` Eric Dumazet
2012-01-28 12:51 ` Wu Fengguang
2012-01-28 13:33 ` Eric Dumazet
2012-01-29 5:59 ` Wu Fengguang
2012-01-29 8:42 ` Herbert Poetzl
2012-01-29 9:28 ` Wu Fengguang
2012-01-29 10:03 ` Eric Dumazet
2012-01-29 11:16 ` Wu Fengguang
2012-01-29 13:13 ` Eric Dumazet
2012-01-29 15:52 ` Pádraig Brady [this message]
2012-01-29 16:10 ` Wu Fengguang
2012-01-29 20:15 ` Herbert Poetzl
2012-01-30 11:18 ` Wu Fengguang
2012-01-30 12:34 ` Eric Dumazet
2012-01-30 14:01 ` Wu Fengguang
2012-01-30 14:05 ` Wu Fengguang
2012-01-30 3:17 ` Shaohua Li
2012-01-30 5:31 ` Eric Dumazet
2012-01-30 5:45 ` Shaohua Li
2012-01-30 7:13 ` Herbert Poetzl
2012-01-30 7:22 ` Shaohua Li
2012-01-30 7:36 ` Herbert Poetzl
2012-01-30 8:12 ` Shaohua Li
2012-01-30 10:31 ` Shaohua Li
2012-01-30 14:28 ` Wu Fengguang
2012-01-30 14:51 ` Eric Dumazet
2012-01-30 22:26 ` Vivek Goyal
2012-01-31 0:14 ` Shaohua Li
2012-01-31 1:07 ` Wu Fengguang
2012-01-31 3:00 ` Shaohua Li
2012-01-31 2:17 ` Eric Dumazet
2012-01-31 8:46 ` Eric Dumazet
2012-01-31 6:36 ` Herbert Poetzl
2012-01-30 14:48 ` Wu Fengguang
2012-01-28 17:01 ` Herbert Poetzl
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=4F256B26.3060309@draigBrady.com \
--to=p@draigbrady.com \
--cc=akpm@linux-foundation.org \
--cc=axboe@kernel.dk \
--cc=eric.dumazet@gmail.com \
--cc=herbert@13thfloor.at \
--cc=linux-kernel@vger.kernel.org \
--cc=tj@kernel.org \
--cc=wfg@linux.intel.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.