Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!rice!sun-spots-request
From: jeremy@bbird4.prime.com (Jeremy Nussbaum)
Newsgroups: comp.sys.sun
Subject: Re: SPARCstation 1 Memory Growth
Keywords: Miscellaneous
Message-ID: <7415@brazos.Rice.edu>
Date: 5 May 90 09:45:29 GMT
Sender: root@rice.edu
Organization: Sun-Spots
Lines: 28
Approved: Sun-Spots@rice.edu
X-Refs:  Original: v9n150, Replies: v9n150
X-Sun-Spots-Digest: Volume 9, Issue 150, message 11

In article <7336@brazos.Rice.edu> rmk@snowhit.att.com writes:

|   In my preparation for future growth in SPARCstation 1 memory, above the 16
|   Meg limit with 1 Meg SIMMS, I prepared the following chart to help us all
|   with this growth.
|...
|   +----------------------------------------------+
|   |         SPARCstation 1 Memory Growth         |
|   +------+---------+---------+---------+---------+
|            [table deleted]

This is all correct.  HOWEVER, there is a 32 Mb limit on the amount of
physical memory that the mmu on the SS's can map at any one time.  While I
do not know the details of what happens when you would really like to have
more than 32 Mb active at one time, it seems that currently you get a full
page fault and lose track of the page thrown out of the mmu mapping to
make room.  In other words, more than 32 Mb or so (+ any unmapped memory)
does not get you anything.  I was told by email from someone at Sun that
they are working on a software cache solution to the problem.  I presume
that means that the page that gets thrown out of the mmu mapping stays in
some unmapped page in memory, and a table is kept of valid pages in
non-mmu mapped memory.  On mmu faults some code is executed to check for
the existence of the requested page in unmapped memory, and if it's there,
only the mm table entry needs to be written; no disk read.  Someday soon,
I hope

Jeremy Nussbaum (jeremy@jeremy.prime.com, ...!harvard!primerd!jeremy!jeremy)
Prime Computer (508)879-2960 x3516