Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rice!sun-spots-request
From: jblind@griffith.eng.sun.com (Joanne Blind-Griffith)
Newsgroups: comp.sys.sun
Subject: Re: Sun-4 MMU Performance
Keywords: SunOS
Message-ID: <10237@brazos.Rice.edu>
Date: 25 Jul 90 03:15:49 GMT
Sender: root@rice.edu
Organization: Sun-Spots
Lines: 63
Approved: Sun-Spots@rice.edu
X-Sun-Spots-Digest: Volume 9, Issue 274, message 11
Originator: spots@titan.rice.edu


	 	   Sun Microsystem's Response to 
	     A Guide to Sun-4 Virtual Memory Performance

 	Joanne Blind-Griffith, Product Manager,	Sun Microsystems.

The recent Sun-Spots posting by Gordon Irlam is essentially accurate in
describing the hardware limitations of the Sun MMU.  As he points out,
whether this limitation is encountered on any particular machine depends
on which Sun hardware is involved and what sort of applications are being
used.  It is our experience that this limitation is rarely encountered
with applications which show typical locality of reference.  Most common
applications and job mixes will never encounter this limit.  However, some
very large applications, and some applications which share memory between
many processes, will encounter this limit.

The Sun MMU design results in a very fast MMU with a minimum of hardware.
The Sun MMU is best thought of as a cache for virtual-to-physical
mappings.  As with all caches, the cache was designed to be large enough
for the sort of typical applications to be run on the machine.  Nearly all
applications achieve a very high hit rate on this cache.  However, like
any cache, there are applications that will exceed the capacity of the
cache, greatly lowering the hit rate.  Since this cache (i.e., the Sun
MMU) is loaded by software, the cost of a cache miss can be quite
expensive.

We have improved the algorithms that manage the Sun MMU.  The improvment
involves adding another level of caching between the MMU management
software and the upper levels of the kernel.  This is a classic space/
time tradeoff where a little bit of space for this software cache saves a
lot of time in reloading the MMU for those applications which exceed the
hardware limits of the MMU.  In addition, many other changes have been
made to the MMU management software to improve performance in general and
to reduce the effects of some worst case behaviour.

Following are the test results using Gordon's vmtest program run on a 12MB
SPARCstation 1+ with the improved MMU management software:

	virtual	elapsed	user	system
	memory	time	time	time
	(MB)	(sec)	(sec)	(sec)
	 2	 2	 2.3	0.6
	 4	 5	 4.7	0.8
	 8	10	 9.4	1.1
	10	13	11.9	1.2
	12	16	14.3	1.4
	14	18	16.8	1.5
	16	21	19.5	1.7
	18	25	22.5	1.9
	20	27	25.3	2.0
	22	30	27.6	2.2
	24	33	30.4	2.5
	26	36	33.3	2.5
	28	39	35.7	2.7
	30	41	38.1	2.9
	32	44	40.8	3.1

Note that the performance is essentially linear through 32MB.

This improved MMU management software will be included in the next release
of SunOS.  It will be available as a patch for SunOS 4.1 (Sun4c and Sun4
platforms) and 4.1 PSR A end of July and for SunOS 4.0.3c (Sun4c machines)
early August.