Page Fault Resolution
13.1. Handling a Typical Page Fault
When a process generates a page fault, the memory management unit hardware signals a bus error, which vectors through the trap page to a routine in the wired portion of the kernel-level fault interceptor manager (FIM). The FIM handles the page fault by calling the memory management subsystem to resolve the fault. (FIMs on reverse-mapped systems check for sharing faults; see Section 13.6.)
Figure 13-1 shows the flow of control between the managers in the subsystem and summarizes the operations that each manager performs to resolve the page fault. The next sections detail the operations performed by each manager.
13-1 Page Fault Re~olution
MMU
....
Disk Manager or Network Manager gets pages
Flpre 11-1. Page Fault Handling
o
o
o
13.1.1. MST Page Fault Handling
The fault interceptor manager calls the MST manager routine mat _ .touch to initiate page fault resolution. The mst _ Stouch routine's function is to locate the virtual segment that contains the faulting address and get the UID and segment number of the object segment mapped to that virtual segment. The mst _ Stouch routine carries out this operation as follows:
I. Calls mst _ $va _ to _ segno to convert the ASID /virtual address passed to it by the fault interceptor manager to an index into the per-process MSTs.
2. Determines whether the page fault is for a page within a private or global segment, and increments the appropriate per-process page fault counter (in procl_tstats).
3. Checks for special segments, if running on a rorward-mapped MMU. Special segments store resources that cannot be paged in and out o( physical memory; for example, AEGIS kernel data structures.
4. Gets the number of pages that should be ideally fetched into memory rrom the touch ahead count count specified in the MSTE and passes this value, plus the object UID and segment number, to the active segment table manager.
13.1.2. AST Page Fault Handling
The AST manager's function in page Cault resolution is to locate the active segment table entry for the segment, and to activate an ASTE (or the segment if it is inactive.
13.1.2.1. AST Locking During Page Fault Handling
Use of the active segment table is controlled by the ast _ $lock resource lock and by the hold count and in transition fields in the ASTE. The AST lock gives the AST manager's caller exclusive use of the AST linked lists. It prevents other AST callers Crom making changes to the state of the AST while the AST manager is searching for an ASTE.
However, the AST lock must be released once the AST is located so that other processes can access ASTEs. Giving up the AST lock makes it possible for the AST manager to deactivate the ASTE before any of the segment's pages become resident and for other callers to change the contents of the ASTE while it is in use.
To prevent the AST replacement algorithm from deactivating the ASTE, the AST manager increments the ASTE hold count each time it is called to use the ASTE. The hold count is similar to the wired page count; other processes can use the ASTE, but it cannot be deactivated.
The AST manager later will decrement the hold count when its caller is finished holding the the ASTE. To block other callers from changing the state o( the ASTE, the AST manager sets the in transition bit when it activates or deactivates an ASTE. The in transition bit indicates that the ASTE is changing and so its contents cannot be trusted. Callers that want to· use an ASTE in transition will wait on an eventcount.
13.1.2.2. Locating and Activating the Segment
The AST routines used to locate and possibly activate a segment differ depending on the type of MMU hardware in use. On reverse-mapped MMUs, the MST manager calls ast _ $touch to locate the ASTE and, if necessary, to activate an ASTE for the segment.
13-3 Page Fault Resolution
On forward-mapped MMUs, mst_Stouch calls ast_Stouch_segva before calling ast_Stouch.
The ast _ Stouch _ segva routine carries out the following steps. It:
1. Gets the AST resource lock, takes the ASTEX specified by the caller and uses it to locate the COI'responding ASTE. If no ASTEX has been given, the routine hashes the given UID to get an ASTEX .
. 2. Compares &he UID and segment page number in the ASTE with the values specified by mst _ Stouch. If they match, the routine reads the in transition bit in the ASTE to make sure that no other caller is using the ASTE; ir the bit is set, ast_Stouch_segva suspends, waitin~ on the AST eventcount ror the bit to clear. Once the ASTE is no longer in transition, the routine must obtain a new ASTEX (by hashing the UID) because· die ASTE on which it was waiting may have been deactivated during the waiting period.
3. Takes the roDowiDg actions when the target ASTE has cleared in transition:
• Increments the ASTE hold count; this ensures that the segment will not be deactivated during the call to ast _ Stouch
• Returns to mst _ Stouch with a probable ASTEX to be passed to ast_$Wuch.
If ast_Stouch_segva cannot locate an ASTE that corresponds to the given UID, it activates an ASTE for the segment by calling ast _ $activate, and makes associations the memory management tables and the faulting virtual add~esses. The routine holds the AST resource lock while it sets up ,he tables; it releases the lock before it returns to mst _ Stouch with the ASTE held and with a probable ASTEX.
The ast _ Stoudt routine locates the ASTE for the segment in the same manner as ast _ Stouch _ segva:
1. Gets the AST resource lock and locates the ASTE that corresponds to the object segment. via the ASTEX or a UID hash.
2. Checks for in transition on a matching ASTE, or activates a new ASTE if it cannot locate a match.
3. Increments- the ASTE hold count and relinquishes the AST resource lock, once it obtains an ASTE.
The AST manager (via at _ Stouch and an internal routine touch) next carries out some checking (described in later sections) and calls pmap _ $touch to bring the requested pages into memory from disk or- frolll another location in the network. Note that the the AST manager (touch) does not have the AST lock when it calls pmap _ Stouch.
13.1.3. PMAP Pqe Fault Handling
The pmap_Stoueh routine retches pages from physical memory, from disk, or from elsewhere on the network. The routine first obtains the resource lock pag _ Slock.
Page Fault Resolution 13-4
~"
(
.' .... -.. ,., .... ,.'
c)
o·
18.1.8.1. Page Locking
Most page fault handling is carried out under the pag _ Slock resource lock. The page resource lock must be held by any routine that makes a change to the state of the paging database: the PMAP and MMAP. However, the page lock cannot be held during I/O; releasing the lock allows other processes to run while the I/O completes. Relinquishing the page lock means that physical pages allocated may be available for page stealing. Therefore, the modules involved· in page fault resolution always set the fields in the MMAPE for the physical page to unavailable, making the page wired, and set the in transition field in the PMAPE; setting these fields prevents the MMAP page replacement routine from stealing the physical pages into which I/O is occurring, and prevents other PMAP callers from seeing those PMAP entries.
18.1.8.2. Determining the Type
or
Page FaultOnce pmap _ Stouch obtains the page lock, it gets the PMAP for the active segment and examines the PMAPE for the first page requested. This page can be in one of the following states:
• The first page is in transition; someone else is using it. If pmap _ $touch finds the first page in transition, it releases the page lock and suspends itself waiting on the page-in-transitioneventcount. When the page clears the in transition state, pmap _ $touch restarts its first page examination.
• The first page is resident - the object-to-physical page association already exists; this is a resident page fault or a sharing fault
• The first page is not resident, in which case it can be:
• Non-resident and existing on a remote disk; this initiates a remote page fault
• Non-resident and existing on local disk; this is the typical page fault
• Non-resident with no backing storage on disk; this state initiates a growth fault
• Non-resident with invalid data in its backing storage on disk; this is a null page fault
The next section explains the typical page fault - how pmap _ $touch operates when it finds that the first page is not resident and exists on local disk.
18-5 Page Fault Resolution
13.1.3.S. Fetching Pages from Disk
When pmap _ $touch determines that the fll'St page is not resident and exists on disk, it next determine! how many more or the pages requested really can be touched by by reading the rest of the PMAPEs Cor the active segment. The routine only attempts to touch consecutive pages, beginning with the first page requested and stopping at the point . that: .
• It exceeds the maximum touch ahead count that the MST manager has specified in the call to ast _ .touch
• The touch ahead coUnt causes a segment boundary to be crossed
• It fmds a page in transition
• It finds a page that is already resident in memory
• It finds a null page
The routine then sets the PMAPEs for the pages it is going to read to in transition so that it can release the pag _ $lock resource lock, and then calls its internal routine alloc to allocate enough physical pages to hold the pages to be read into memory. The alloc routine in turn calls the :M:MAP manager (mmap _ $allocate), which actually allocates the pages Crom the Cree list or by its replacement algorithm.
If the ~1MAP manager cannot locate enough physical pages to satisfy the number of pages that alloc has requested, it indicates to alloc that there are no physical pages available. The alloc routine then releases the page lock and advances the page purifier's eventcount, which awakens the purifier to Cree up some physical pages by writing their contents out to disk. The alloc routine waits for the purifier to return it some physical pages; when it does, the routine then obtains the page lock again and returns to its caller with the page lock held.
Once enough physical pages have been allocated, pmap _ $touch unlocks the page _ $lock lock and calls the disk driver (disk_$read_ahead) to get the pages off disk into physical memory. When the disk driver returns, pmap _ $touch then calls the MMAP manager (mmap _ Sinstall_list) to update the MMAP with the new physical pages, and updates the PMAPE for each newly resident page by:
• Copying in the disk addresses (low Cor reverse-mapped MMUs)
• Setting the resident bit
• Setting the valid bit (on forward-mapped MMUs)
The pmap _ $touch routine also updates the ASTE number oC pages resident count.