Date: Sun, 19 Sep 1999 11:01:12 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Matthew Jacob <mjacob@feral.com> Cc: 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 (was: cvs commit: src/sys/miscfs/specfs spec_vnops.c src/sys/sys vnode.h src/sys/kern vfs_subr.c) Message-ID: <199909191801.LAA73219@apollo.backplane.com> References: <Pine.BSF.4.05.9909191020230.41966-100000@semuta.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> :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
<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?199909191801.LAA73219>