From owner-cvs-all Sun Sep 19 11: 3:46 1999 Delivered-To: cvs-all@freebsd.org Received: from proxy2.ba.best.com (proxy2.ba.best.com [206.184.139.14]) by hub.freebsd.org (Postfix) with ESMTP id 33173151D9; Sun, 19 Sep 1999 11:03:41 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com ([209.157.86.2]) by proxy2.ba.best.com (8.9.3/8.9.2/best.out) with ESMTP id LAA17731; Sun, 19 Sep 1999 11:01:12 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA73219; Sun, 19 Sep 1999 11:01:12 -0700 (PDT) (envelope-from dillon) Date: Sun, 19 Sep 1999 11:01:12 -0700 (PDT) From: Matthew Dillon Message-Id: <199909191801.LAA73219@apollo.backplane.com> To: Matthew Jacob Cc: Poul-Henning Kamp , dg@root.com, Greg Lehey , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: User block device access (was: cvs commit: src/sys/miscfs/specfs spec_vnops.c src/sys/sys vnode.h src/sys/kern vfs_subr.c) References: Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk :> :to fix the block dev interface is not a very hard problem. :> : :> :-- :> :Poul-Henning Kamp FreeBSD coreteam member :> :> The buffered block device is not slow, I don't know where you get :> that idea from. It is, in fact, just about as fast as you can get and :> still cache the data, which is to say somewhat faster then normal file :> access would be. The cache is flushed on every open of the device :> which may be causing your confusion. There is no overhead beyond the :> normal overhead associated with caching a file. : :It can be slow for reads, but fast for writes if you have a good :clustering mechanism. Negative, it will not be slow for reads. The block device issues read-aheads based on a similar heuristic that normal file reads use, but limited to a single block. If the data is not in the cache a second memory copy is incurred, but this is also true of a file read. The first iostat below is with a dd if=/dev/ccd0d of=/dev/null bs=32k (ccd is created across da1 and da2), incuring the maximum overhead (cache miss on every read): test3:/root# iostat 1 tty ccd0 da0 da1 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 1 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 0 38 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0100 0 39 8.00 3395 26.51 0.00 0 0.00 8.00 1700 13.28 1 0 25 5 70 0 39 8.00 3542 27.67 6.00 1 0.01 8.00 1768 13.81 0 0 26 8 67 0 39 8.00 3441 26.88 0.00 0 0.00 8.00 1722 13.45 0 0 32 7 62 0 39 8.00 3432 26.81 0.00 0 0.00 8.00 1716 13.41 0 0 33 4 64 0 39 8.00 3443 26.90 0.00 0 0.00 8.00 1721 13.44 1 0 31 4 64 0 39 8.00 3441 26.89 0.00 0 0.00 8.00 1723 13.46 1 0 28 5 67 0 39 8.00 3433 26.82 0.00 0 0.00 8.00 1715 13.40 0 0 28 6 66 The second iostat is with a dd if=test of=/dev/null bs=32k where the file is on a filesystem created on ccd0d test3:/root# iostat 1 tty ccd0 da0 da1 cpu tin tout KB/t tps MB/s KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 1 0.00 0 0.00 0.00 0 0.00 0.00 0 0.00 0 0 0 0100 0 40 62.49 121 7.39 0.00 0 0.00 31.93 120 3.75 0 0 5 2 93 0 38 63.56 446 27.67 0.00 0 0.00 31.82 446 13.86 0 0 18 3 79 0 38 63.88 456 28.47 0.00 0 0.00 31.95 456 14.24 0 0 19 2 78 0 38 63.75 450 27.99 0.00 0 0.00 31.89 450 14.00 1 0 16 1 82 0 38 63.75 449 27.98 0.00 0 0.00 31.89 449 14.00 0 0 19 3 78 0 38 63.75 450 27.99 0.00 0 0.00 31.89 450 14.00 0 0 20 5 75 0 38 63.75 449 27.98 0.00 0 0.00 31.89 449 14.00 0 0 18 4 78 0 38 63.88 456 28.47 0.00 0 0.00 31.95 456 14.24 0 0 17 2 81 0 38 63.75 450 28.05 0.00 0 0.00 31.95 450 14.05 0 0 20 4 76 You could characterize this as 'slightly slower' but you could not characterize this as 'slow'. The slight loss in performance is simply due to the smaller block size (2K vs 8K), the fact that we aren't VMIO'ing the block device, and the shorter read-ahead. Except for the lack of VMIO these tend to effect only the sequential access case so I've never been particularly worried about it. I suppose it could be 'fixed'. I don't think it's a big deal. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message