Curt Sampson wrote:
>On Mon, 15 Nov 1999, Cliff Crawford wrote:
>
>> A similar problem occurs in the macppc port.  Try building a new kernel
>> with the line:
>> 
>> options BUFPAGES=800
>
>The problem is lack of kernel VM space to map the buffers. Doing
>that would give you not a heck of a lot of buffer space, which is
>really a waste on a machine with that much memory. The solution is
>to set MAXBSIZE smaller so that you can map in more buffers. On my 512 MB
>SS20 I use
>
>options         MAXBSIZE=32768
>options         NBUF=5120
>options         BUFPAGES=14000

NBUF I can guess at: the number of buffers. MAXBSIZE would be
size of a buffer (in bytes?). So what is a bufpage?

I'm assuming this particular issue isn't unique to the sparc
port. Is this a correct assumption?

I'm looking at options(4) on the i386 port and nbuf and bufpages
are described as ``often calculated as between 5% and 10% of
total available RAM.'' For machines with a lot of ram, is it
possible to force calculations to be something like 5% to 15% of
available ram instead of a fixed number?

I saw Be demo once, and the guy said BeOS uses as much free ram
as possible for cache, and scale back the size of the cache as
memory-needs increase. To my naive ears, this sounds like a
better strategy when dealing with free memory (if it's there,
why not use it?). Comments?

WL