sid@linus.UUCP (Sid Stuart) (04/26/85)
We have a Sun 170 with one (soon two) Fujitsu Eagles and two megabytes of memory that is used strictly as a disk server. I have been thinking that we could get an increase in speed on the diskless nodes if we increased the number of buffers available for file I/O and for swapping. The default number of buffers is what can be contained in about 10% of the memory on the machine. Not having Sun source code available tonight, I looked at the code for my 780. On a Vax the number of buffers is calculated in /sys/vax/machine.c. To increase the number of buffers available from 10% of memory to 50% on the Vax, I would just change the line: "bufpages = (physmem * NBPG) / 10 / CLBYTES; to something like: "bufpages = (physmem * NBPG) / 2 / CLBYTES; " I figure the code is similar in the Sun kernal. I have two questions before I attempt this though: First, in the code below where the bufpages is calculated, the available buffers are split between file I/O buffers and swap buffers. Then the number of swap buffers is limited to be at most 256. Next to this limit operation is the comment, "sanity". Does that mean I have to be insane to increase the number of swap buffers above 256? Second, I figure the guys at Sun are a lot smarter than I am, why haven't they put something like this in their code for disk servers? (This one has me worried.) Waiting for wisdom, sid ps. Thinking about the buffering between disk servers and diskless nodes brings up another interesting question: Are swap pages from a diskless node held in file buffers or swap buffers on the disk server?
chris@umcp-cs.UUCP (Chris Torek) (04/27/85)
Well, it doesn't quite work that way. "bufpages" is the amount of
memory allocated for buffer space; this is distinct from the number of
buffers ("nbuf") since in 4.2, a buffer is only as big as the disk
block it is supposed to hold. Pages are moved from one buffer to
another (by zapping pte's) as necessary. If you have file systems that
are blocked 4k/512, bufpages is generally twice as big as it ought to
be, since the code that allocates nbuf based on bufpages assumes that
buffers average MAXBSIZE bytes. (This is all ignoring the swap I/O
buffer header stuff, but the swap buffer headers are really just
headers; they point into space that becomes owned by the pagedaemon
during pageouts.)
Anyway, you can increase the number of local buffers by filling in
a value in "nbuf" in /vmunix (it's in initialized data space) and
rebooting. Turning on "syncprt" (if Sun left it in) will also make
the console show how much buffer memory is in use and how much is
free, which can help you decide what nbuf ought to be set to.
As far as the network disk code goes: well, increasing nbuf won't make
that much difference, probably, since ndstart() is only willing to
queue up 4 transfers to the server before it waits for one of them to
finish:
while ((bp = dp->b_actf) != NULL && nd_nsenttoserv < 4) {
and so forth. But it will help keep useful information cached.
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@maryland