Date: Sun, 19 Sep 1999 11:25:39 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Matthew Jacob <mjacob@feral.com>, Poul-Henning Kamp <phk@critter.freebsd.dk>, dg@root.com, Greg Lehey <grog@lemis.com>, cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: User block device access Message-ID: <199909191825.LAA73396@apollo.backplane.com> References: <Pine.BSF.4.05.9909191020230.41966-100000@semuta.feral.com> <199909191801.LAA73219@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Here are the results from accessing the buffered block device through
a ccd with a disk label specifying a larger, 64K block size, to match
the clustering that is accomplished with a file:
dd if=/dev/ccd0d of=/dev/null bs=32k (w/label specifying 64K block size)
test3:/root# iostat 1
tty ccd0 :24932 >ú16 cpu
tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id
0 39 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0100
0 38 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0100
2 58 64.00 309 19.31 0.00 0 0.00 0.00 10121981 0.00 0 0 8 1 91
0 40 64.00 463 28.96 0.00 0 0.00 0.00 15181333 0.00 0 0 12 2 87
0 41 64.00 463 28.96 0.00 0 0.00 0.00 15184235 0.00 1 0 10 0 89
0 41 64.00 460 28.78 0.00 0 0.00 0.00 15119854 0.00 0 0 12 2 86
0 41 64.00 463 28.96 0.00 0 0.00 0.00 15183363 0.00 0 0 12 3 85
0 40 64.00 464 29.02 0.00 0 0.00 0.00 15183137 0.00 0 0 16 1 83
0 41 64.00 462 28.90 0.00 0 0.00 0.00 15183167 0.00 0 0 12 2 86
As you can see, performance jumps ahead of what you get with a file
via a ccd-mounted filesystem. The cpu performance too, is better then
what you get when accessing a normal file.
Comparing this against the raw ccd partition:
dd if=/dev/rccd0d of=/dev/null bs=64k
test3:/usr/src/sys/miscfs/specfs# iostat 1
tty ccd0 :24932 (c`16 cpu
tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id
2 56 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0100
4 40 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0100
4 45 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0100
1 42 64.00 360 22.52 0.00 0 0.00 0.00 11809165 0.00 1 0 3 3 93
0 41 64.00 463 28.96 0.00 0 0.00 0.00 15183152 0.00 0 0 7 2 90
0 41 64.00 463 28.96 0.00 0 0.00 0.00 15183438 0.00 0 0 2 1 97
0 41 64.00 463 28.96 0.00 0 0.00 0.00 15183062 0.00 0 0 4 3 93
0 40 64.00 463 28.96 0.00 0 0.00 0.00 15183287 0.00 0 0 5 0 95
0 41 64.00 464 29.02 0.00 0 0.00 0.00 15239761 0.00 0 0 1 1 98
0 41 64.00 463 28.96 0.00 0 0.00 0.00 15183378 0.00 1 0 4 4 90
And the difference you see in cpu overhead is, of course, due to the
fact that the raw device is incuring one less copy then the block device,
and the block device tests are being performed in such a way as to incur
a 100% cache miss ratio on the block device.
The advantage of the raw device exists only when you compare it against
a buffered device which never gets a cache-hit. The moment you run it in
a real-life situation where the idea is to utilize the caching the
buffered block device gives you, the buffered block devices blows away
the raw device for obvious reasons.
To demonstrate the performance that caching gives you in situations where
you expect to take advantage of it, a simple program to open a block
device and read the same few megabytes over and over again results in
memory-copy performance rates.... several hundred megabytes a second while
the raw device is still stuck at the platter rate.
It is inappropriate to contrive 'examples' that supposedly demonstrate
the superiority of the raw device without taking into account the purpose
of using the buffered device in the first place -- i.e. to be able to
take advantage of its caching capabilities.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199909191825.LAA73396>