---------------------------------------------------------------------------- Sun Microsystem's Response to A Guide to Sun-4 Virtual Memory Performance SunFLASH Vol 19 #22 July 1990 ---------------------------------------------------------------------------- This response was just posted to Sun-Spots. The reference article by Gordon Irlam describes some limitations of the Sun 4 MMU. This problem is loosely refered to as 'the PMEG stealing problem'. The next SunFlash article will provide a program that reports on PMEG stealing. In this response Joanne Blind-Griffith acknowledgs the problem and promises a fix to SunOS 4.1 by the end of July and a fix to 4.0.3 by early August. Note that SunDBE does not have this problem. - johnj ---------------------------------------------------------------------------- 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.3 (Sun4c platforms) early August. ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Sunflash is an electronic mail news service from Sun Microsystems, Ft. Lauderdale, Florida, USA. It is targeted at Sun Users and Customers. As a field sales and support office, we try to keep SunFlash useful and interesting to you. If you have any comments or suggestions for enhancing SunFlash, please send them to us. SunFlash is ditributed via a hierarchy of aliases. Please try to address change requests to the owner of the alias that you belong to. Please address comments to the SunFlash editor John McLaughlin (sun!sunvice!flash or flash@sunvice.East.Sun.COM). (305) 776-7770.