From owner-cvs-all Sun Sep 19 11:27:48 1999 Delivered-To: cvs-all@freebsd.org Received: from proxy4.ba.best.com (proxy4.ba.best.com [206.184.139.15]) by hub.freebsd.org (Postfix) with ESMTP id 095DE15292; Sun, 19 Sep 1999 11:27:43 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com ([209.157.86.2]) by proxy4.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id LAA19587; Sun, 19 Sep 1999 11:25:39 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA73396; Sun, 19 Sep 1999 11:25:39 -0700 (PDT) (envelope-from dillon) Date: Sun, 19 Sep 1999 11:25:39 -0700 (PDT) From: Matthew Dillon Message-Id: <199909191825.LAA73396@apollo.backplane.com> To: Matthew Jacob , Poul-Henning Kamp , dg@root.com, Greg Lehey , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: User block device access References: <199909191801.LAA73219@apollo.backplane.com> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message