O Directory segments
4. RESTRICTION IN CORE SIZE
When we restrict our configuration to have a firiite amount of core, we reach the true Multics case where multiplexing is necessary. In addition to the functions previously described, the page multiplexor must also be responsible for finding a free block of core when all blocks are being used. This condition requires a selection algorithm for removing pages from core to secondary storage; and this
algorithm requires a new data base - the core map used block list.
The two lists of core blocks - free and used - are implemented by means of an entire core map. The core map consists of one core map entry (CME) for each l024-word block of core. Each entry serviced by the page fault handler is threaded into one of the two queues - free or used - depending upon its current status, but the entry and its physical block remain associa-ted throughout any change in status. The free list is
singly threaded, since only its first element 1.s ever used, but the used list is circularly threaded to allow continuous searching.
The actual information contained in a CME can be deduced from the part it plays in the removal algorithm. Clearly 'it must allow one to obtain the absolute core location of the
beginning of the l024-word block. But a pOinter to the PTW for the page currently residing in the block is also
necess8TY if the block is being used, since the removal of the page means that access to it should be inhibited by setting a page fault in the PTW which controls it.
The sequence of actions for handling a page fault in the liDdted core environment is:
1) As before, get the fault, find the device address from the segment map in the ASTE.
2) Access the core map free list to obtain a free block: if successful, place a pOinter to the·
PI'W in the CME selected, tmthread the CME from the free list, flag it as being used for
rIo
and thread it into the used list. (Continue at Step -6) •3) If the free list is empty, perform the replenishment algorithm to find a block in which the referenced page can be put.
The replenishment algorithm is driven by a bit in the·PI'W called the "Page has been used" or PHU bit.
This bit is set by the 645 hardware whenever the page is accessed. ~eIl a page must be removed, the used block list of the core map is accessed and the entries are examined in the order of their
threading, starting where the last search stopped.
Each entry is examined to determine whether the PHU bit has been turned on. Each page's PHU bit is turned on by the software when the page is brought to core, but after each examination during the removal algorithm the page fault handler turns it off. Therefore, the effective criterion for removal is whether the page has been used since it was last examined for removal. (For further information about the philosophy of this algorithm, see "A paging experiment with the Multics System", F. J.
Corbato, Multics Repository Document MOI04.) 4) Having fotmd a candidate for removal, set a page
fault in the PTW, determine the device address from the ASTE and call the DIM to transport the page to secondary storage.
In order to avoid 1.mnecessary page transportation, the 645 hardware maintains a "page has been modified"
bit in each PTW which is turned on only if the page has been written into. Unless this bit is on, the page need not be returned to secondary storage.
5) In contrast to the page important strategy, do not wait for this page to be moved, but continue to
select candidates for removal and call the DIM to transport them until a block appears on the free list. This block will have been placed on the free list by the DIM when a page has been completely transported.
6) Using the device address developed in step 1), call the DDM to import the desired page into the newly acquired block of core.
7) Call the Traffic Controller to wait for the page to arrive.
8) Since the PTW's page fault switch and CHE's I/O busy switch are reset by the process which called the Traffic Controller to awaken the waiting pro-cess, the page fault has been entirely repaired and the page fault handler may return.
Figure I is a gross flow chart of the page fault handling strategy as described in Section 4. Special pOints of interest are:
1) Any call to the DIM, whether for reading or writing, causes all transactions to be observed and the com-pleted ones to be "posted". The posting process for a write operation consists of threading the CME out of the used list and into the free list.
For a read, posting requires that the page fault switch be reset and tb~t any processes which might be waiting for the page to be imported be informed of its arrival (through the Traffic Controller).
2) The call to the Traffic Controller to wait for a page to be read is only made for reasons of
efficiency and plays no logical part in the page fault handling strategy.
;,..
No
Is there a·
free block on the free list
Yes Unthread from free list, flag for I/O and add to used list
DIM (read)
Yes Wait via the
traffic controller
No
No
Put block on free
list
Figure 1. The Page Fault Handler
DIM (write)
Update used list next block ointer