If a page is not in transit, a page frame of real storage aust be
allocated to fill the request. Before the allocation routine is called,
a test is made to see if the caller wishes the return to his routine or
to be delayed until after the requested page is available. If the DEFEB option is not requested, DMKPTBAN returns to the caller after first
building and stacking a CPEXBLOK that allows processing of the page
request to be continued the next time the dispatcher (DftKDSPCH) is
entered. DMKPTBAN next calls the FBEELIST manager (DMKPTBFB) to obtain the
address of the next available COBTABLE entry. DftKPTBFB aaintains a
first-in-first-out list of the COB TABLE entries for those page fraaes
that are immediately available for assignment. As DMKPTBFB releases
these page frames, a check is made to see if the number of entries on
the FREELIST has fallen below a dynamically aaintained ainiaua value. If
it has, the page selection routine (SELECT) is called to find a suitable
page frame for placement in the FBEELIST. The number aaintained as the
FREEL 1ST threshold has a value equal to the number of users in queue1
plus the number of users in queue2 plus 1.
The FBEELIST is replenished directly by users releasing virtual
storage space. The page-out routine, DftKPGSPO, calls DftKPTBFT to place
released page frames directly on the FBEELIST. However, aost replenishment is done via the page selection routine, SELECT. SELECT is
called by DMKPTBFB when the FBEELIST count falls below the current
minimum, or when a user page is reclaimed fro. the FBEELIST. In either
case, the selection algorithm attempts to find a page to swap to
auxiliary storage. The highest-priority candidates for a swap are those
page frames whose COBTABLE entries appear on the FLUSHLST. SELECT attempts to take a flushed page frame before it takes a page fraae froa an active user. If such a page frame is found, it is checked to see if
it has been changed since page-in •. If it has not, it is placed in the
FBEELIST by DMKPTBFTi otherwise, it is scheduled for a swap-out by dequeuing the COBTABLE entry from the FLUSHLST, constructing a CPEXBLOK for dispatching after I/O completion, and exiting to DMKPAGIO by a GOTO. After the paging I/O is complete, the entry is placed on the FBEELIST via a call to DMKPTBFT. If no pages are found on the FLUSHLST, the selection algoritha
examines each page in real storage, searching for an available page that
does not have its reference bit It begins the search at the first
available page at the high end of real storage and searches by
descending page address. When it reaches the lowest available page
address, it starts again from the top of storage. When a page has been
found, that page address minus one is checkpointed. The next tiae the
selection algoritha is invoked, it starts from the checkpointed address.
As the selection process proceeds, those pages that were not selected
have their reference bits turned off. When the selection algoritha is
operating in this mode, a virtual page must be referenced at least once
per reset cycle (loop around real storage) to avoid selection. Once a page frame has been selected and page-out is scheduled,
control is returned to DMKPTBFB, which then passes control back to DMKPTBAN with the address of the COBTABLE entry that was allocated. In most cases, page-outs are completely overlapped with page-ins.
Approxiaately one half of all page-ins require a corresponding page-out. Once a page frame has been assigned, DMKPTBAN checks to see if a
page-in is required. It usually is, and the DASD address of the virtual
storage page aust be obtained froa the user's swap table entry and the I/O operation scheduled. However, if the page frame bas not yet been
referenced (as indicated by a DASD address of zero), the real aain storage page frame is set to zero, and no page-in is required. After CP Introduction 1-109

the page-in operation has been queued, DMKPTRAN exits to the paging I/O scheduler (DMKPAGIO), which initiates the paging operation and exits to
the dispatcher (DMKDSPCH) to await the interruption. Some requests for main storage page frames are handled differently from general virtual-to-real storage mapping. In particular, it may be
necessary for CP to obtain additional free storage for control blocks, I/O lists, buffers, etc. This is handled by the free storage manager,
which makes a direct call to DMKPTRFR to obtain the needed storage. Usually, this storage is immediately available (due to the page
buffering technique previously described). However, if the FREELIST is
exhausted, the request for free storage is recognized as a high-priority
call and queued first on the list of those waiting for free page frames.
The real storage manager (DMKPTR) accumulates paging statistics that
the scheduler (DMKSCH) uses to anticipate user storage requirements. A
count of page-reads and page-writes is kept in each virtual machine's VMBLOK; the corresponding total counts for the system are kept in DMKPSA. A running total of the number of pages a virtual machine has
resident. at each instance of oaqe-read. is keot in the VMBLOK. A count of the number of times a virtual machine enters page-wait, because a
page frame has been stolen from it, is also in the VftBLOK. The
section entitled "Controlling Multiprogramming" under "Dispatching and Scheduling" describes the use to which the scheduler puts these counts. Vft/310 The VM/310 virtual=real option involves the mapping in a one-for-one correspondence of a virtual machine storage
area with an equivalent real storage area. For instance, virtual page 1
is in real page frame 1 and virtual page 20 is in real page frame 20. Virtual page 0 is relocated at the end of the virtual storage space
because 'it cannot occupy real page frame O. The CP nucleus is altered at system generation to support the
virtual=real option. Virtual machines with virtual=real (specially
identified in the directory) can then log on and use the space reserved
for this option. That space can be used by only one virtual machine at a time. Two virtual machines with the virtual=real capability cannot
occupy the same space at the same time. The virtual=real option allows the virtual machine to bypass the
control program's CCi translation. This is possible because I/O from a
virtual machine occupying a virtual=real space contains a list of CCis
whose data addresses reflect the real storage addresses. The
restriction in this situation is that the virtual machine does not perforg I/O into page frame 0 because this would perform a data transfer
into real page frame O. At the same time, it is assumed, and cannot be
checked, that the virtual machine also does not attempt to do I/O beyond
the bounds of its virtual addressing space. To do so would cause the
destruction of either the CP nucleus, which resides beyond the virtual machine space, or another user's page.
If the real I/O device is an MSS 3330V, then CCi translation is not
bypassed since CP must still be able to recognize an ftSS cylinder fault. See Appendix B for details.
The bypassing of CCi translation for the virtual machine occupying
the virtual=real space is only invoked after the virtual machine has
executed the SET NOTRANS ON command. This command can only be issued by
the virtual machine occupying the virtual=real space. The command initiates the bypass of CCW translation. This option is automatically turned off if the virtual machine perforas an explicit reset or an
implied reset by performing a virtual IPL. During virtual aachine IPt, I/O must be performed into page frame O. For this reason, normal virtual IPL simulation assumes CCw translation in effect to accomplish 1-110 IBM VM/370 System Logic and Problem Determination--Volume 1