exceeds the real paging space available in the system). Thus, the
paging manager must keep statistics On system and virtual machine paging
activity and make these statistics available to the dispatcher to detect
and prevent a potential thrashing condition.
Inefficiency in the second area causes an unacceptable ratio of CP
overhead to virtual machine program time, and in extreme cases may cause
CP to use excessive processor time. To understand how allocation is
determined by CP, the way in which the inventory of real storage page
frames is described to the system must be understood.
Each page frame (4096-byte block) of real storage in the system is in
one of two basic states: nonpageable or pageable. 1 nonpageable page must remain resident in real storage for some period of time; thus, the
page frame cannot be taken from its current owner to be given to someone
else. Pages can be either permanently or temporarily nonpageable,
depending upon their use. Temporary locks usually occur when an I/O operation has been
initiated that is moving data either to or from the page, and the page
must be kept in real storage until the operation has completed.
A page can also be temporarily nonpageable if it contains an active
nonresident CP routine.
In addition, a page can be nonpageable through use of the LOCK command. Pages locked this way are permanently resident until they are
explicitly unlocked by the UNLOCK command. Pages that are usually
considered peraanently nonpageable are those that contain the resident
portion of CP and those that contain the system's free storage area in
which control blocks, I/O buffers, etc., are builto
The data area that page management routines use to control and
allocate real storage is the CORTIBLE. Each page frame of real storage
has a corresponding entry in the CORTIBLE, and because the table entries
are fixed in length and contiguous, the entry for any given real page
fraae may be located directly by indexing into the table. Each entry
contains pointers that indicate both the status and ownership of the
real page that it represents. Some pointers link page table and swap
table entries to the real page (and thus establish ownership), while others link the entry into one of several lists that the paging routines
use to indicate the page frame's status and availability for paging. 1 given CORTIBLE entry may appear on either of two lists if its real page
frame is available for paging; however, if the page referenced is locked
or is in transit, its entry is not in either list and is not referenced
when available page frames are being searched for swap candidates. The
lists are known as the free list (FREELIST) and the flush list (FLUSBLST), and they represent various levels of page frame availability. • The free list contains page frames that are immediately available for
assignment to a requesting virtual machine. The virtual storage
pages for which they were last used have either been released by
their owners or they have been paged out to auxiliary storage.
Requests for real storage are always satisfied from the free list.
If the list bas been depleted, the requestor waits until a new page frame becomes available as the result of a virtual storage release or
a swap-out. • The flush list contains page frames that belong to those virtual
machines that have been dropped from an active dispatching queue. The
flush list is the first place that the page frame selection routine
looks to find a page to swap out or to assign to the free list for a
virtual machine that requires real storage space.
CP Introduction 1-101

• The scheduler aids the page selection algorithm by notifying it of
virtual machines that are no longer eligible for dispatching (either
because they have completed or because they are being held suspended
in the eligible list). The scheduler calls the page reset routine
when a virtual machine is dropped from a queue and does not immediately reenter the dispatch list. Under heavy paging loads, it
is the responsibility of the page reset routine to group all
in-storage virtual pages belonging to the virtual machine on an
available (or flush) list for easy selection by the page replacement algorithm.
Requests for real storage fall into two general categories; those that
are requesting space for a page of virtual storage, and those (such as
requests for CP work space) that need page frames for their own use. The former, more general case is discussed first, because the latter case is
a subset of the first.
The main page manager routine, D!KPTRIN, maps a request for a
specific virtual storage address into a page frame of real storage.
This requires that the virtual page be read in and the necessary tables be updated to shOW the proper status of the page frame. D!KPTRIN requires that the caller supply only the virtual address to be translated and any options that apply to the page to be located. Most calls are made via the TRINS macro, which sets up the necessary
parameters, determines whether or not the required page is resident, and
calls D!KPTRIN if it is not. When D!KPTRAN receives control, it first tests to see if the
requested page is resident. This is done via the LRI instruction. If
the page is resident, the routine locks the page if requested and exits
to the caller. If the LRI indicates that the page is unavailable, it is
still possible that the required page is resident. This occurs if the
page frame has been placed on the FREELIST but has not been assigned to
another virtual machine. When the page swap routine removes a page frame from a virtual machine, the unavailable bit is set in the
corresponding page table entry; however, the real main storage index for
the page frame is left unchanged. The page table entry is set to zero
only when the corresponding page is actually assigned to another virtual machine. Thus, if D!KPTRIN finds the page unavailable, a further test
is made on the page table entry to see if the page can be reclaimed. If
the entry is not zero (aside from the unavailable bit), the CORTIBLE entry for the page frame is removed from the FREELIST and the page frame is returned to the calling virtual machine. If the page table entry corresponding to the requested virtual page
is zero, the required page is not in real storage and must be paged in.
However, it is possible that the page is already on its way into .ain
storage. This condition is indicated by a flag in the SWPTIBLE entry for
the virtual page. The D!KPIGIO routine maintains a queue of CPEXBLOKs to
be dispatched when the pending page I/O is complete. The CPEXBLOK for
the page in transit is located and a new CPEXBLOK, representing the
current request, is chained to it.
Before exiting to wait for the paging operation to co.plete, DftKPTRIR checks to see if the deferred return (DEFER option) has been specified.
If it has not, D!KPTRIN returns to the caller. If the DEFER option has
been requested, D!KPTRAN exits to the dispatcher to wait for page I/O co.pletion. When the requested page has been read into real storage, the
list of CPEXBLOKs are unstacked first in first out to satisfy all
requests for the page that arrived while it vas in transit. 1-108 IBM VM/370 System Logic and Problem Deteraination--Volume 1