Virtual storage aanagement is done by the technique known as de.and
paging. This means that a page of virtual storage is not "paged in" froa its DASD auxiliary storage area until it is needed. CP does not
determine the pages required by a virtual aachine before the virtual machine executes. A demand for a page can be .ade either i.plicitly by the virtual lIachine or explici tl y by CP. An implicit demand for a page is made when a program atte.pts to
reference a page that is not available in real .ain storage. This attempt causes a program interruption with the interruption code
indicating a page or segment exception. Upon recognition of this
condition, control is passed to the paging manager to obtain a page
frame of real .ain storage and to bring in the desired page. An explicit delland for a page can be made by CP (for exa.ple. in the
course of translating a user's channel program). If, in the process
of translation, CP encounters a CCW that addresses a page that is not
resident in real storage, a call is made to the paging .anager to make the referenced page resident. While the requested page is being fetched, the requesting virtual
machine is unable to continue execution; however, it may be possible to
run other tasks in the system, and CP runs these while the needed page
is being paged in. When the requested page is resident, the virtual machine can be run and is dispatched in its turn.
In addition to demanding pages, virtual machines i.plicitly or
explicitly release page frames of their virtual storage space. Part of
the space may be explicitly released from both real and virtual storage
via a DIAGNOSE instruction that indicates to the control program those
page frames that are to be released. An entire virtual storage is
released when a user loads (via IPL) a new operating systea or logs off from the syste •• CP also has virtual storage associated with it. This space contains CP (solie parts of which need not always be resident in real storage).
and virtual storage buffers for spooling and systea directory
operations. Although CP makes use of virtual storage space for its
execution, it does not run in relocate mode. Thus, nonresident .odules aust be coapletely relocatable.
Real storage manage.ent allocates the system's page fraaes of real
storage to satisfy the demands for virtual pages aade by the syste.'s
virtual lIachines. Efficiency of allocation involves a trade-off; the
paging manager uses only enough processor time to ensure that: The set of virtual storage pages that are resident represent those
pages that are IIOSt likely to be used. A sufficient number of cycles is available to execute virtual aachine
progra.s.
Inefficiency in the first area causes a condition known as thrashing.
which means that frequently used pages are not allowed to re.ain
residant long enough for useful work to be perforaed by or on thea. Thrashing could be aggravated by the paging manager's page fra&e selection algorithm or by a dispatcher that attempts to run more tasks
than the system can handle (the SUII of their storage requirements 1-106 IBM VM/310 System Logic and Problem Deteraination--Voluae 1
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
Previous Page Next Page