z/VM 5.2.0 64-bit Considerations
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.
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
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.
Return to the Performance Tips Page