> On Sun, 26 Jan 1997 14:08:44 +0100 (MET) 
>  hannken@serv1.eis.cs.tu-bs.de (Juergen Hannken-Illjes) wrote:
> 
>  > Maybe the change of thorpej to sys/arch/sparc/sparc/machdep.c (Dec 22, 1996):
>  > 
>  >   +       /*
>  >   +        * XXX stopgap measure to prevent wasting too much KVM on
>  >   +        * the sparsely filled buffer cache. 
>  >   +        */
>  >   +       if (nbuf > 128)
>  >   +               nbuf = 128;
>  > 
>  > If I understand the buffer management, the difference is as follows:
[snip of clustering problem]

> ...unfortunately, some systems (e.g. SS1s) crap out from the large
> amount of KVA space required by the buffers.  *sigh*
> 
> I agree with you that my change should be backed out, and I guess
> the SPARC port should probably back MAXBSIZE down to 32768 until
> all this gets resolved.

Yeah, this is probably a good idea. I had to reset MAXBSIZE to 16k (what
it used to be; didn't try 32k) and remove the nbuf > 128 test in order to
get my machine to boot again.

Now that NetBSD/sparc supports sun4m's with lots of main memory, perhaps
it is time to lower the kernel's start address to 0xf0000000 or something.
This would certainly help alleviate the buffer cache kva crunch. I'm not
sure how this will affect the MMUs on the sun4c's--will they run out of 
pmegs for the kernel? On the sun4m, it only costs a bit more wired pagetable,
which IMHO is worth being able to use the larger buffer cache.

(of course, the right solution is to merge the buffer cache and VM system,
but I'm not holding my breath...)

What do others think?

--Aaron