Subject: Re: enlightenment on zs overruns
To: None <greywolf@starwolf.starwolf.com>
From: Chuck Cranor <chuck@dworkin.wustl.edu>
List: port-sparc
Date: 11/22/1997 20:15:19
>4096?  Does this mean that the actual number of process slots cannot
>exceed this number, i.e., can only 4096 processes run on the machine
>at any given time?

>...or am I way off base here and completely misreading what you've writ?

you are off base.   what it means is that with a sun4/sun4c MMU, a
single process address space is described by a segment map which
has 4096 entrys.


so the virtual address breaks up like this:

             +----------------------------> must equal bit 29
             |        +-------------------> 12 bit segment map entry# (0-4095)
             |        |       +-----------> 6  bit page table/pmeg entry# (0-63)
             |        |       |       +---> 12 bit offset in page (0-4095)
             |        |       |       |
sun4c bits: [31-30] [29-18] [17-12] [11-0]      pagesize = 4k
sun4  bits: [31-30] [29-18] [17-13] [12-0]      pagesize = 8k
 |           |        |       |       |
 |           |        |       |       +---> 13 bit offset in page (0-8191) 
 |           |        |       +-----------> 5  bit page table/pmeg entry# (0-31)
 |           |        +-------------------> 12 bit segment map entry# (0-4095)
 |           +----------------------------> must equal bit 29
 |
 +-- all sun4's except SUN-4/400 which has a 3 level MMU 
 
 
note that because bits 31 and 30 must be equal to bit 29, there is a
"hole" in the virtual address space from 0x20000000 to 0xdfffffff where
no pages can be mapped.
 
   
the "4096" paul was referring to is the segment map entry number from
the virtual address.
 
 
the sun4/sun4c MMU stores all the tables used to translate addresses
in special memory [_not_ main memory] which can only be accessed with  
special instructions.    this special memory is divided into segment
maps (or contexts) and page tables.    if a segment map or page table
for a process is missing from the special memory, then a trap is generated
and the proper data must be loaded into the MMU by the pmap module.
so, in some sense, the MMU special memory is caching the data stored in
the pmap structure.
 
   
in the sun4 MMU there are 16 segment maps.   in the sun4c MMU there are
8 segment maps.   since each running process requires a segment map, these
8 or 16 segment maps must be shared between all processes on the system.
if a process needs to run and all segment maps are in use, then it steals
a segment map from another process (i.e. it kicks the other process out).

likewise, there are a limited number of page tables in the MMU that
must be shared between the segment maps.   for example, a sun4/300
has 256 page tables.


if you look at cpu.c at cpumatch_sun4() you can see where these
values get set in sc->mmu_ncontext (number of segment maps)
and sc->mmu_nsegment (number of page tables -- mmu_nsegment is kind
of a poor name for it if you use my names to describe it).   sun4c 
asks the openprom for these values.

i describe the 3 level 4/400 MMU on my web page if you are interested.
see http://dworkin.wustl.edu/pub/chuck/notes/notes.html under
the sparc section.

chuck