Text preview for : 19770714_Page_Faults_and_Multiple_Processes_per_MDS.pdf part of xerox 19770714 Page Faults and Multiple Processes per MDS xerox sdd memos_1977 19770714_Page_Faults_and_Multiple_Processes_per_MDS.pdf
Back to : 19770714_Page_Faults_and_ | Home
Inter-Office Memonmdum
To Pilot, Mesa, DO architecture Date 14 July 1977
From Paul McJones Location Palo Alto
Subject Page faults and multiple processes Organization SO~/SO
per MOS
XEROX XEROX SDD ARCHIVES
Archive " I have read and understood
Pages To
-----
Filed on: # of Pages ____ Ref .. 11SpJ) - 2.7 I
With the current processor architecture, running multiple processes capable of taking page
faults within a single MOS leads to problems. If significant resources (Le. one or more
resident frames) are not to be dedicated on a per-process basis, changes to the processor are
indicated. Two different proposed changes are sketched here. Additionally, an analogy is
drawn between handling page faults, which requires dedicated, resident frames, and
handling frame heap allocation traps, which requires dedicated (possibly nonresident)
frames. Each of the proposed hardware changes can be extended to handle frame heap
allocation traps.
Handling a page fault requires a definite amount of resident memory for local frames. In a
system which chooses not to ded icate this memory on a per-process basis, there must be a
way to queue a fault until sufficient such memory is available to handle it. The current
processor architecture, in which page fault handler frame space is associated with the MOS,
does not provide an efficient way to dedicate this frame space specifically to page fault
handling, or to regulate accesses to it by multiple processes within the MOS. One remedy
for this situation would maintain the association of frame space for handling page faults
with an MDS, but would provide a way to suspend a faulting process until enough of the
space is available. Another remedy would decouple the handling of page faults from any
particular MDS by converting page faults into messages, thereby achieving the necessary
serialization of access to dedicated frame space using the "dual" approach to the first
proposal.
The situation now
Traps
Currently every processor-detected trap forces the running process to execute a
KernelFunctionCal1 (KFC) instruction with an offset in the SD (system dispatch table)
determined by the particillar trap. The SD entry must contain either a procedure descriptor
or a pointer to a fixed frame. In the former case, a call is clone, which implies allocating a
new local frame from the frame heap. In the latter case, execution continues in the fixed
frame.
Handling page faults
The page fault handler must be very c:ueful about generating page faults. In particular, the
original I Several ways to prevent this suggest themselves:
Page faults and multiple processes per MDS 2
1. Pin the whole frame heap in resident pages. While it may be that the frame
heap will. be "hot" enough that it will all stay resident anyway, it would be nice to
avoid the logical necessity to pin it; the rest of this memo is concerned with how to
do that.
2. Reserve an entry of the AV (allocation vector) for the page fault handler and
stock it with resident frames. There seem to be several ways to run multiple
processes per MDS in this scheme. The second and third schemes below are not
intended as solutions in themselves, but as motivation for the hardware-change
proposals to follow.
a. Reserve enough resident frames to handle a page fault by each process.
b. Reserve resident frames for fewer instances of the page fault handler
than there are processes. This requires additional reserved resident
per-process frames (2?) for a "first level page fault handler" procedure
which invokes a monitor to wait until enough frames are available to handle
the fault. Later we will look at how the "first level handler" could be
pushed into the hardware, eliminating the per-process reserved frames.
c. Use the idea of a "first level handler" in a different way, to send a
message describing the page fault; one or more processes running in an
environment with dedicated resident frames would receive such messages and
handle the page faults. In a large system with many MDS's this would allow
sharing among them the page fault handler's dedicated frames. Later we will
look at how the one (?) resident frame per process required by this scheme
on the current hardware could be saved by pushing the message-sending
"first level handler" into the hardware, making It attractive even in a small
system with one MDS and minimal real memory.
3. Use a fixed frame for the page fault handler (and probably for all the code it
calls). This does not seem fruitful: there is no way to prevent another process from
entering this frame before the first one has returned from it.
Monitors as currently defined