MVS Real Storage Control Mechanisms
When looking at the real and virtual storage mechanisms of MVS, it is important to remember that MVS is not a paging system. That is, MVS does not manage real storage by paging; real storage management is done primarily by swapping. Paging in MVS provides several critical improvements over the earlier IBM systems:
micsrm140
When looking at the real and virtual storage mechanisms of MVS, it is important to remember that MVS is not a paging system. That is, MVS does not manage real storage by paging; real storage management is done primarily by swapping. Paging in MVS provides several critical improvements over the earlier IBM systems:
- More efficient use of real storage. Paging completely eliminates the external fragmentation of the MFT and MVT systems.
- Provides the application with a large virtual memory. MVS largely removed issues of memory management from applications.
- Improvements in data and system integrity. A dynamic addressing scheme makes this much easier to accomplish.
- Increase in the number of concurrent jobs. The S/360 and S/370 architecture has a maximum of 16 storage protection keys. In the MFT and MVT systems, this would be a severe limitation on batch throughput. In MVS, because of the protection afforded by dynamic addressing, all user (problem state) work except for V=R jobs may use the same protect key.
- Supports Swapping
Swapping in a non-paging environment would be much more complex because of address relocation issues.
Because of this design, the MVS paging algorithms are vastly different (and more complex) than those of a system whose primary means of real storage control is through paging. Management of storage is divided among the three subsystems (RSM, ASM, and VSM) described below:
Real Storage Manager (RSM)
The Real Storage Manager (RSM) maintains the control blocks that translate real and virtual storage address, makes the determination of working set contents when an address space is swapped, and performs the page replacement operations.
Auxiliary Storage Manager (ASM)
The Auxiliary Storage Manager (ASM) manages the page and swap data sets that comprise the virtual space. The page data sets provide the auxiliary storage that backs up the storage frames. Prior to the introduction of the extended swap facility (provided either by the Installed User Program (IUP) or with MVS/SP 1.3), the swap data sets contained only the LSQA frames from swapped-out address spaces. The private frames were paged out. With the extended swap processing, the LSQA pages and the working set of the address space are written out together to the swap data sets. This concept is discussed in detail in RSM Standard Output.
Virtual Storage Manager (VSM)
The Virtual Storage Manager (VSM) provides a map of the private area virtual storage within each address space. VSM interfaces with RSM to handle the dynamic allocation of virtual memory.
Storage Management Technology
MVS uses a least-recently-used (LRU) page replacement algorithm to keep a number of free pages to be used for page allocations and swap-ins. Through the progression of the MVS Systems Extensions and System Product Releases, the real storage algorithms have been refined and additional capabilities have been added. The remainder of this section defines the operation of the page replace and storage control algorithms and traces some of the historical development of these processes.
Swapping
The resource use functions of the SRM attempt to optimize the use of system resources on a systemwide basis. It does this through multiprogramming level adjusting, CPU load balancing, I/O load balancing, storage load balancing, and demand or logical swapping.
Swapping is the primary method used by the SRM to effect this control. Using IPS and OPT parameters and system status information, the SRM determines which address spaces should have access to system resources.
There are a number of reasons for swapping. The first three described below control domains and the address spaces within a domain, while the next four control system performance and throughput.
Unilateral If the number of active address spaces for the Swap In: domain is less than the value specified in the IPS or less than the SRM deems optimal, the SRM swaps in address spaces for the domain.
- Unilateral Swap-Out
- If the number of active address spaces for the domain is greater than the value specified in the IPS or greater than the SRM deems optimal, the SRM swaps out address spaces for the domain.
- Exchange Swap
- All address spaces within a domain compete with one another for system resources. When an address space has consumed its allotted resources and another address space in the same domain is waiting to be swapped in, the SRM swaps out the one in real storage and swaps in the other.
- Swaps Dueto Storage Shortages
- If auxiliary storage or pageable frame shortages occur, the SRM swaps out the address space that is acquiring auxiliary storage at the fastest rate or the address space with the greatest number of fixed frames. It continues this operation until the shortage is corrected.
- Swaps Due to Wait States
- In certain cases the address space signals the SRM that it is a candidate for swap-out. This occurs when it can be determined that the address space will not become eligible for execution for a relatively long time. Examples are an ENQ for a resource currently held by a swapped-out address space or an STIMER wait of greater than 0.5 seconds.
- Request Swap
- The system may request that an address space be swapped out. For example, the VARY STOR,OFFLINE command requests the swap-out of address spaces that occupy frames on the storage unit to be taken offline.
- Transition Swap
- A swap occurs when the status of an address space changes from swappable to non-swappable. This special swap prevents the job step from improperly using reconfigurable storage.
The SRM adjusts the multiprogramming level by adjusting the number of address spaces that are held in real storage for each domain. When the paging rate becomes excessive, the SRM reduces it by swapping out address spaces to reduce paging. If the rate is too low, the SRM swaps in address spaces to increase it.
The SRM adjusts the CPU load level by swapping in eligible address spaces if the CPU utilization is too low or swapping out address spaces if the CPU utilization is too high.
The SRM adjusts the I/O load level by swapping in or out address spaces to maintain the proper utilization of the system's logical I/O channels.
The SRM adjusts the storage load level by swapping in or out address spaces to keep real memory properly utilized.
The SRM effectively utilizes real storage and reduces channel and processor overhead by logically swapping some address spaces. Rather than swapping them to auxiliary storage, they are left in real storage whenever possible. This is done if the system determines that the address space will be ready to execute in a relatively short period of time.
With the advent of RMF 4.2, four new swap reasons are reported, which are used to manage work flow and resource commitment. The SRM monitors the utilization levels of various system resources and attempts to bring these levels to within site-specified limits by swapping address spaces out of central storage. In addition, the SRM may respond to an address space experiencing a wait condition during an APPC conversation by swapping the address space.
Swapping may be performed in order to improve the system paging rate. If the SRM has been set up to manage the system paging rate, and that rate rises above the maximum acceptable level, the SRM will cause address spaces to be swapped out in an attempt to lower the rate.
Swapping may also be performed in order to improve central storage usage. If the SRM has been set up to manage central storage, and demand for storage rises above the maximum acceptable level, the SRM will cause address spaces to be swapped out in an attempt to lower the demand.
Swapping may occur to make room in central storage to swap in an address space that has been swapped out too long. The SRM monitors the duration of swap-outs, and if no other condition has made it possible to swap in an address space that has been swapped out for a long time, the SRM will make room in central storage for it by swapping out other address spaces.
During an APPC conversation, an address space issuing an LU6.2 call to the APPC address space can experience a wait condition. When this occurs, the SRM can then make a decision whether to swap the calling address space out or not.
UIC Update Process
Maintaining a record of the time since each page was last referenced is central to the implementation of a LRU page replacement algorithm. This function, called the UIC (unreferenced interval count) update process, is actually implemented by the same routine that performs the page stealing function. We will discuss the two functions separately in order to make it easier for you to follow the developmental changes to each of the processes.
The UIC records the number of seconds since the page has been referenced. The system UIC is thus the age in seconds of the oldest page in storage. In Figure 2-30, the rates for UIC updating for various values of the system UIC are presented for both swappable and non-swappable address spaces.
Figure 2-30. UIC Update Rates
------------------------------------------------------------ | System UIC |0-2| 3-5| 6-7| 8 | 9 | 10-13 | 14 | 15+ | |-----------------+---+----+----+---+---+-------+----+-----| | Swappable (sec) | 1 | 1 | 1 | 1 | 2 | 2 | 2 | 2 | | | | | | | | | | | | Non-swap (sec) | 1 | 2 | 3 | 3 | 3 | 4 | 5 | 6 | ------------------------------------------------------------
For example, if the system UIC is six, then the UIC for non-swappable address spaces is updated every three seconds.
The UIC for swappable address spaces needs to be maintained more closely in order to effectively trim to the working set on a swap out. For non-swappable address spaces, it is not necessary to keep close track of the working set if the demand for real storage is light. This also gives some page stealing protection for non-swappable address spaces.
Page Steal Algorithm
The page replacement process in MVS maintains a queue of free pages to use in satisfying requests for new pages. This queue, called the Available Frame Queue (AFQ), is replenished by stealing pages from the address spaces in real memory. Page stealing is performed based on various values of the UIC of each page. Thus the UIC is used to define the working set of each address space. The changes described in this section were made in response to various operational problems that were discovered with continued field experience with MVS.
These changes were always made with two primary objectives in mind:
- To achieve a balance holding enough page frames on the AFQ.
- To distribute the burden of paging across the address spaces in real memory.
In MVS/XA and MVS/ESA systems, the page steal process takes four pages from each address space or common area before making a second pass to steal more pages.
The page stealing process is invoked when the available frame queue falls below a threshold and steals enough pages to maintain the queue at a target level. When the page stealing process is invoked, the RFR takes all pages whose UIC equals the system UIC. No differentiation is made between address spaces.
This algorithm corrects problems of the previous algorithms. It also tends to steal more pages from the types of address spaces that were previously favored, the low CPU users. Thus, the non-swappable online systems (e.g., CICS) that use their pages less frequently than other address spaces experience heavier paging rates.