z/VM 5.2.0 64-bit Considerations

Introduction

z/VM 5.2.0 includes much improved exploitation of large real storage sizes. Consequently, prior VM systems with 2GB-line performance constraints should no longer have these constraints after they are migrated to z/VM 5.2.0. This discussion is about the remaining 64-bit considerations when running on z/VM 5.2.0.

See Pre-z/VM 5.2.0 64-bit Considerations for a more detailed discussion of the 64-bit storage constraint on prior releases, including how to see if a constraint is present and suggestions on how to reduce the constraint.

Background

Prior to z/VM 3.1.0, CP did not support real storage sizes larger than 2 GB -- the extent of 31-bit addressability. Starting with the 64-bit build of z/VM 3.1.0 through z/VM 5.1.0, CP was changed to provide a limited form of support for real storage sizes greater than 2G. All CP code and data structures still had to reside below the 2G line and most of the CP code continued to use 31-bit addressing. Guest pages could reside above 2G. They could continue to reside above 2G when referenced by 64-bit-capable CP code using access registers but there are only a few places in CP that do that. Normally, when a guest page that mapped to a real storage frame above 2G had to be referenced by CP (as, for example, during the handling of a guest I/O request), it first had to be moved to a frame below the 2G line before it could be manipulated by the 31-bit CP code. In large systems, this sometimes led to contention for the limited number of frames below 2G, limiting system throughput.

CP runs in its own address space, called the System Execution Space (SXS), which can be up to 2G in size. Prior to z/VM 5.2.0, the SXS was identity-mapped -- that is, all logical addresses were the same as the corresponding real addresses. With z/VM 5.2.0, the SXS is no longer identity-mapped, thus allowing logical pages in the SXS to reside anywhere in real storage. Now, when CP needs to reference a guest page, it maps (aliases) that page to a logical page in the SXS. This allows most of the CP code to continue to run using 31-bit addressability while also eliminating the need (with minor exceptions) to move pages to real frames that are below the 2G line. In addition, the CP code and most CP data structures can now reside above 2G. The most notable exception is the Page Management Blocks (PGMBKs), discussed below.

64-bit Considerations on z/VM 5.2.0

The z/VM 5.2.0 storage management changes summarized above should effectively remove any 2G-line constraints being experienced by current VM systems. The most significant remaining limitation is that the PGMBKs must still reside below 2GB in real memory.

A PGMBK includes the page tables and related page management tables for a 1-megabyte segment of virtual storage. Each PGMBK is 8 KB in size and is pageable. When resident, a PGMBK is backed by two contiguous real storage frames below the 2G line. There is one resident PGMBK for every active one-megabyte segment of virtual storage, where "active" means that it contains at least one page that is backed by a real storage frame. The fact that PGMBKs must still reside below 2G sets an absolute maximum of 256 GB to the amount of active virtual storage that z/VM 5.2.0 can support. (The actual maximum is somewhat less because of other data that still must reside below 2G as well.) Most z/VM systems are far below this limit but it is more likely to become a factor as systems become larger.

Performance Toolkit for VM can be used to check PGMBK usage. Go to the FCX134 screen (Shared Data Spaces Paging Activity - DSPACESH) and look at the data for the PTRM0000 data space. (Normally, there is just one PTRM00nn data space but systems having large amounts of virtual storage can have up to 16 of them.) "Resid" is the number of frames being used for PGMBKs and the number of PGMBKs is half that amount. (Note: In z/VM 5.1.0, this count is in error and is, in effect, a count of PGMBKs rather than PGMBK frames.)

Since the System Execution Space (SXS) is limited to a maximum of 2 GB, it represents another resource that can become constrained. We don't expect this to become a problem on z/VM 5.2.0. You can use the QUERY SXSPAGES command to check SXS utilization at any moment in time. SXS utilization is 100 times "Total SXS Pages in Use" divided by "Total SXS Pages". Performance Toolkit for VM can be used to see SXS utilization over time. Go to the new "System Execution Space Utilization" report (SXSUTIL; FCX264) and use the "Total Pages Used" and "Total Pages" values. SXS storage management is designed to keep aliases in place until SXS pages are needed for some other purpose. Consequently, the "Total Pages Used" count tends to overstate the true requirements.

Once all SXS pages are in use, additional aliased pages cause older ones to be stolen. The alias steal rate is shown by the "Steal" column in the "System Execution Space Page Management" report (SXSPAGE; FCX262) provided by Performance Toolkit for VM. An alias steal rate below several thousand per second should not have any appreciable effect on overall performance.