2. PERFORMANCE REPORTING ANALYSIS › 2.2 Real Storage Management Analysis › 2.2.4 MVS Concepts › 2.2.4.1 Virtual Storage Concepts › 2.2.4.1.2 Paging Concepts
2.2.4.1.2 Paging Concepts
Having settled on paging as the method of providing virtual
storage, three issues that have a large impact on the final
design must be considered. These are page size, the method
of mapping a virtual to a real address, and the determination
of which pages should remain in real storage.
PAGE SIZE DETERMINATION
In MVS, to remain compatible with S/360 and S/370 storage
protection features and existing storage allocation software,
a page size that was a multiple of 2 KB was dictated. MVS
chose a page size of 4 KB, accepting that potentially 4095
bytes of storage could be wasted.
The choice of page size is a compromise between the amount of
storage lost to internal fragmentation and the size of the
tables that translate virtual addresses to real addresses
(the Page Tables).
Another issue in considering the page size is the page
transport time, that is, the time required to write the page
to auxiliary storage. With the 16 MB virtual address space
provided by MVS through SP1.3, the 4 KB page size has worked
well. In later systems, even though the amount of virtual
storage has been increased to 2 GB, the page size has
remained 4 KB. This size remains in use today with z/OS.
The remainder of this chapter uses the terms page, frame, and
slot in a very specific manner as defined below:
o Page - A unit of virtual storage (4 KB or 4096 bytes in
MVS).
o Frame - A 4 KB unit of real storage that contains data for
some virtual address (a page).
o Slot - A 4 KB unit of space (on a direct access storage
device) that holds the data contents of a page when it is
not occupying a frame in real storage.
VIRTUAL ADDRESS TRANSLATION
The second issue to be considered is the mapping of virtual
to real storage addresses. A simple structure would be to
have each virtual address be a page number and displacement
within the page. The problem with this implementation is
that it requires the entire page table to be allocated at all
times. In MVS/370, the page table would have been 4096 pages
for each active task; in later operating systems the number
would have become 128 times greater.
The solution to this problem is to divide the virtual address
into fixed segments. In MVS/370, there are 256 segments,
each representing 64 KB of the virtual address space. Each
segment then is defined by 16 pages. In MVS/XA and later
systems, to accommodate the much larger virtual storage,
there are 2048 segments, each representing 1 MB of
address space. Each segment is divided into 256 pages.
In all systems, the virtual address is a triplet (s,p,d),
that is, a segment number, page within the segment, and
displacement within the page. The control program then only
needs to have page tables for active segments. The page
tables define all valid pages belonging to the program. If
the page is in real memory, the page table contains the
starting address of the page. If the page is not currently
in real storage, the page table contains a status bit that
indicates this fact. A complete description of the hardware
supporting virtual address translation is found in the
Principles of Operation.
Figure 2-36 shows how the segment and page tables map virtual
addresses to real addresses. In MVS, if we do not consider
the extended virtual addressing schemes, a virtual address is
24 bits, or 6 hexadecimal digits of the form:
sspddd
where: ss = segment number (0 - 255)
p = page number (0 - 15)
ddd = page offset (0 - 4095)
If the 31-bit addressing scheme is used, a virtual storage
address is of the form:
sssppddd
where: sss = segment number (0 - 2047)
pp = page number (0 - 255)
ddd = page offset (0 - 4095)
Note that the leftmost bit of the sss field is not used.
Starting with MVS/SP 1.3, support was added for real
addresses greater than 24 bits in length. This is
accomplished by adding two bits to the real addresses in the
page tables. The changed support thus provides for 64
MB of real storage. When frames are assigned to
pageable storage areas, an available frame from either below
or above 16 MB (the maximum 24-bit address) can be
used. However, when a page is fixed (usually for I/O to be
done), if the page is currently occupying a frame above the
16 MB address, it must be moved to a frame below 16 MB,
because the channels only support 24-bit addressing.
PAGE REAL
TABLES MEMORY
FRAMES
-----------
| page 255|--\ -------
|---------| \ |PGM 2|
SEGMENT | | \ |-----|
TABLE +--->| : | ---->|PGM 1|
| | : | |-----|
--------------- | | | |PGM 4|
| Segment 2047|----+ |---------| |-----|
|-------------| | page 0 |--+ |PGM 4|
| | ----------- | |-----|
| : | | |PGM 3|
| : | | |-----|
Virt__| : | | |PGM 2|
Adrs | | | |-----|
| | | +--->|PGM 1|
|-------------| | | |-----|
| Segment 2 | +--+--->|PGM 1|
|-------------| | |-----|
| Segment 0 |----+ | |PGM 3|
--------------- | ----------- | |-----|
| | page 255|-----+ |PGM 2|
| |---------| |-----|
| | : | -->|PGM 1|
| | : | / |-----|
+--->|---------| / |PGM 4|
| page 1 |--\ / |-----|
|---------| X----->|PGM 1|
| page 0 |--/ -------
-----------
Figure 2-25. MVS/370 Virtual to Real Address Translation
PAGE MANAGEMENT STRATEGIES
The final issue is to determine which pages should be in real
storage. There are two parts to this question: how should
pages be brought into real memory, and which pages should be
replaced when more real memory is required? These algorithms
are called fetch and replacement strategies.
Several fetch strategies have been used in various systems.
Some of these are:
o To load all pages of a program before execution.
o To try to predict which pages will be used and to fetch
these pages in advance of their reference.
o To bring in pages as they are needed.
In MVS, a combination of these ideas is used. When a program
is initiated, all of its pages are brought into real memory
by the program load facility (fetch). This process works in
the following manner:
o Virtual storage is allocated for the program with the MVS
virtual storage management component (VSM), that is,
GETMAIN.
o Assignment of real storage frames to back up the virtual
storage is done by the real storage management component
(RSM).
o The virtual storage (that is, the range of virtual
addresses to be occupied by the program) is page-fixed to
prevent page stealing during the loading process.
o The program is now brought into real storage from the load
library (a direct access data set such as SYS1.LINKLIB)
into its assigned virtual locations.
o After the I/O to read the program into virtual storage is
completed, the pages are freed, that is, the normal demand
paging process is now allowed to operate on the program
just loaded.
At this point, the pages are subject to the normal page
replacement process. However, under normal circumstances,
some time must pass before this will occur, since all the
pages are "recently referenced" at this point.
Once execution begins, pages that have been paged out are
brought into real memory as they are referenced. This scheme
is called demand paging, that is, pages are brought into
memory as they are "demanded."
The idea of bringing in the entire program initially is to
avoid forcing the program to establish its initial set of
necessary pages by repeatedly demand paging until it can get
down to work. It also serves to provide a means of getting
the program backed up in auxiliary storage through the
existing page replacement facilities, rather than directly
allocating Auxiliary Storage Manager (ASM) slots and writing
the program to them.
As part of the MVS page replacement process, a queue of free
frames is maintained by RSM. This queue, called the
Available Frame Queue (AFQ), serves several functions:
o It reduces the time required to resolve a page fault,
since page fault resolution does not (normally) have to
wait on a page-out to complete.
o The length of the AFQ determines how often page
replacement processing is done.
o By maintaining a reservoir of free frames, MVS can more
easily meet sudden demands for relatively large numbers of
pages (such as that of the program load process just
described and for the swap-in process.)
When all the frames comprising real memory are allocated and
a program requires a page that is not currently in memory, a
page must be selected to be written back to auxiliary storage
to make room for the new page. The goal of the page
replacement process is to select a page for replacement that
will not be referenced again for a relatively long time.
Historically, several methods have been tried:
o First In, First Out - Select the oldest page in the system
for replacement.
o Working Set - Only replace pages that a program has not
used for a given period of time.
o Least Recently Used - Replace the page that has not been
referenced for the longest period of time.
Modified pages that are selected for replacement must be
written to the auxiliary storage to preserve the changes. If
a page that is queued to be written is referenced again
before the actual I/O occurs, the page is said to be
reclaimed. A high reclaim rate indicates a problem, since
this means the page replacement strategy is not working
properly (that is, it is selecting pages to write out that
are being quickly and/or frequently rereferenced).
MVS uses a global Least Recently Used (LRU) algorithm.
Theory and practice have shown that this method also gives a
good approximation to the ideal: to replace a page that is
not likely to be referenced again soon. It turns out that
the application of this strategy also gives a practical
definition of a program's "working set."
The concept of a working set was created to explain a
particular problem. Early virtual systems were subject to a
phenomenon called "thrashing," which occurred when the page
replacement strategy broke down. This happens when replaced
pages are immediately referenced (and therefore must
immediately be brought back into real storage).
Peter Denning explained thrashing in terms of a program's
working set. That is, at any point in time, each program has
a minimal number of pages that it requires to run in a
virtual environment. When the program's working set is
available, all is well. According to the theory, when pages
are stolen from a program's working set, paging increases
exponentially until the system is doing nothing else. Thus,
thrashing is characterized by an excessive amount of CPU time
being expended by the RSM and ASM components of the operating
system.
The MVS real storage management algorithms do a good job of
preventing thrashing from occurring. When it does occur in
MVS, it is usually because the system minimum
multiprogramming level (MPL) as specified in the Installation
Performance Specifications is too large. Working set
concepts are discussed further in Section 2.2.4.2.2. The MVS
storage management algorithms and storage controls are
discussed in Section 2.2.4.3.
Copyright © 2014 CA.
All rights reserved.
|
|