While z/VM has 64-bit support for virtual storage and can support more than
2GB of central storage (real memory), there are areas of the Control Program
(CP) that are limited to 31-bit (2GB). A guest page can reside above 2GB and
have instructions in it executed or data referenced without being moved. However,
pages that require certain CP processing must reside below 2GB in z/VM's central
storage (host real memory). This includes things such as I/O channel programs
and data (both traditional SSCH and the newer QDIO), simulation of instructions,
and Locked pages (e.g. QDIO structures for real devices).
For example, if a guest is executing an I/O where the channel program and data
area reside in a guest page which is in a frame (4KB of central storage) above
2GB, then when CP does page translation (in order to process the virtual I/O)
the guest page is moved to a frame of central storage below 2GB. In the case
of I/O, that page is locked until the I/O completes. Once the page is moved
below 2GB host real, it remains there until it is stolen or the guest storage
is reset (guest logoffs or system reset). This can occur for both guests that
run with 31-bit and 64-bit addressing. The determining factor is not the location
of the the page within guest memory, but the location within z/VM (host real)
memory.
A page can be stolen as part of the CP steal processing which is started when
the number of available frames below 2GB is too low. During steal processing,
CP makes various passes in attempt to add frames to the available list. Each
pass represents a step in the hierarchy of page value. For example, unreferenced
pages of idle users will be stolen before pages owned by CP. There is a separate
steal process for pages above 2GB. When stolen, a page will be moved to expanded
storage if available. This is one of the reasons configuring expanded storage is
highly recommended. If
there is significant contention on the storage below 2GB, thrashing can occur.
The page rates to expanded storage, and potentially DASD, grow to very large
rates (1000s pages below per second). In this thrashing scenario, the pages
stolen from below 2GB will often be ones that will need to be brought back below
2GB in a short period of time.
Test scenarios with Linux guests larger than 2GB executing big amounts of disk
I/O have shown significant throughput degradations compared to Linux guests
with smaller memory sizes or Linux systems running in LPAR.
As a solution to avoid such effects a special feature is implemented in the
Linux DASD driver to limit the number of pages used for channel programs and
data buffers.
How a constraint with 2GB can be identified is described here:
http://www.vm.ibm.com/perf/tips/2gstorag.html
|
