Subject: Re: sun4c slowness again
To: Jason Thorpe <thorpej@shagadelic.org>
From: Chuck Silvers <chuq@chuq.com>
List: port-sparc
Date: 10/15/2006 10:35:04
On Thu, Oct 12, 2006 at 10:37:35AM -0700, Jason Thorpe wrote:
> 
> On Oct 11, 2006, at 4:18 PM, Izumi Tsutsui wrote:
> 
> >As you can see in systat output, there is no paging so it isn't
> >memory shortage, but shortage of "Page Map Entry Group" in MMU.
> >
> >http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/sparc/sparc/machdep.c#rev1.230
> 
> Perhaps a better change to keep UBC from consuming the PMEGs would be  
> to disable lazy-unmapping of the UBC windows.  E.g. ARM does this  
> because of its VIVT cache arrangement, but it might be worth doing on  
> e.g. small SUN4C machines because of the limited number of PMEGs.
> 
> Hm, well, at least the ARM *USED* to do this -- it looks like  
> ubc_release() has since changed to allow the caller to specify "unmap  
> or not".  Ah, I see, it's now done only for VTEXT vnodes via the  
> UBC_WANT_UNMAP() macro.  Hm.
> 
> I'm not exactly sure I like exposing PMAP_CACHE_VIVT to file systems  
> like that.  Instead, I think I'd rather have UBC_WANT_UNMAP() become a  
> function (or, at the very least, consult a global variable that MD  
> code can set).  That way the SUN4C could also indicate that it wants  
> windows to be unmapped as well.
> 
> Chuq?

it's not really clear that the UBC mappings are the problem.
on sun4c machines, UBC mappings are limited to using 4MB (out of
a total of 64MB that can be mapped simultaneously by the hardware).
that's only 6% of the total, so something else is using most of the
PMEGs.  cpu_startup() used to limit ubc_nwins to 256, but that got
increased to 512 somewhere along the way, you could try changing it
back and see if that makes any difference.  but even if we eliminated
the caching of these mappings altogether, it probably wouldn't be long
before something else would change and the problem would reappear.

we need to figure out what the rest of the PMEGs are being used for.
it would be simple enough to write a function to print out the address
space and base virtual address for each PMEG, and then call that from
ddb when the machine is in slow mode.

-Chuck