Subject: Re: DEc 3rd sup; SPARC 1+ dies with all pmegs gone
To: Rob Healey <rhealey@MR.Net>
From: Paul Kranenburg <pk@cs.few.eur.nl>
List: current-users
Date: 12/04/1996 23:21:07
> real mem = 37699584
> panic: me_alloc: all pmegs gone
> 

This is probably a side-effect of increasing MAXBSIZ to 64K. This causes
the disk cache buffers to be mapped sparselier.  The amount of physical
memory allocated to the buffers remains the same, but virtual memory
needs will have increased 4-fold. In your case, there would have been
460 cache buffers (unless you overrode the defaults) spread over a
virtual memory range of about 30MB.

This is not something the sun4c MMU design does easily cope with. A PMEG
is a piece of MMU hardware real-estate, which is able to hold 64 page
table entries (PTE). Whenever you want to map a page, you need to allocate
a PMEG that will hold its PTE if one is not already available. Now, in
the case of the disk buffer map, you wind up using just 4 PTEs out of the
available 64 in each PMEG. The other 60 are wasted because of the sparse
nature of the virtual memory allocated to disk cache buffers.

As a workaround, I suggest overriding the number of cache buffers in your
kernel configuration file to reduce to onslaught on MMU resources.
E.g. `options NBUF 128' will cause the amount of virtual memory needed
to be reduced by about 75%, while the amount of physical memory allocated
to the buffer cache will remain the same.

-pk