Return to BSD News archive
Xref: sserve comp.os.386bsd.questions:16855 comp.unix.bsd.freebsd.misc:6
Path: sserve!newshost.anu.edu.au!harbinger.cc.monash.edu.au!msunews!uwm.edu!vixen.cso.uiuc.edu!howland.reston.ans.net!nctuccca.edu.tw!news.cc.nctu.edu.tw!news!gate!taob
From: taob@gate.sinica.edu.tw (Brian Tao)
Newsgroups: comp.os.386bsd.questions,comp.unix.bsd.freebsd.misc
Subject: Disk block caching algorithm in FreeBSD 2.0/2.1
Date: 2 Mar 1995 05:20:16 GMT
Organization: Computing Center, Academia Sinica
Lines: 34
Message-ID: <3j3kig$iuf@gate.sinica.edu.tw>
References: <3iab71$5qu@gate.sinica.edu.tw> <3is55v$eq7@gate.sinica.edu.tw> <3it2ta$n8c@deep.rsoft.bc.ca> <3ivlsc$lfo@shell1.best.com> <3j3ip0$mra@helena.MT.net>
NNTP-Posting-Host: taob%@gate.sinica.edu.tw
X-Newsreader: TIN [version 1.2 PL2]
[ note cross-posting to comp.unix.bsd.freebsd.misc ]
Nate Williams (nate@trout.sri.MT.net) wrote:
:
: Because David Greenman and John Dyson have beat on the VM and I/O system
: *heavily* to improve the performance of FreeBSD. The VM system in
: FreeBSD is NOT 4.4lite anymore, but a brand-new system almost completely
: re-written. In FreeBSD 2.1, it has changed even more, and is now merged
: with the buffer cache to improve performance even more. Expect even
: greater performance when 2.1 is released.
This is only marginally related to the VM core routines, but I
thought I'd toss it in here. How does FreeBSD cache disk block reads?
Does it cache everything that comes over the SCSI bus, or just i-node
blocks, or just data blocks, or what? I ask because of the heavy
thrashing that occurs when I use 'xdvi' to preview a DVI file under X.
For those not familiar with xdvi, it is an X11-based previewer for
DVI (device-indepedent) files. DVI's are produced by typesetting
programs such as TeX/LaTeX. It scans directory trees for bitmapped
fonts needed to generate the preview. I originally had my XDVIFONTS
variable set to "/usr/local/lib/texmf/fonts//" (the double slash means
recursively search from that directory down). So each time it needed a
font, it would scan down that tree for a matching bitmap.
The "problem" arises when there are more than one font in the DVI
file. I can hear the disk thrash through the same seek patterns for
*each* font. It takes only a few seconds per font, but when you have a
dozen font/size/style combinations in a document, you can end up
waiting close to a minute for the preview to appear.
Since xdvi is only examining the file inodes in the directory
blocks and not the files themselves, shouldn't FreeBSD be able to cache
those blocks and then have xdvi fetch them from RAM?