relegating those virtual machines that have a high I/O-to-compute ratio to the main
processor, and those virtual machines that have a high compute-to-I/O ratio to the
attached processor. Such decisions should be carefully weighed as every virtual
machine is in contention with other virtual machines for resources of the system.
A system programmer can improve a virtual machine's performance on a multi­
processor where the path(s) to a user's primary minidisks exist from one processor
only. In such cases, the system programmer could set the user's affinity to that
processor.
A more important use of the affinity setting would be in applications where there
are virtual machine program requirements for special hardware features that are
available on one processor and not the other. Such features could be a perform­
ance enhancement such as virtual machine assist (described later in the text) or a
special RPQ that is a requirement for a particular program's execution.
Multiple Shadow Table Support
Shadow Table Bypass
To reduce the number of purges when the virtual machine changes control register
1 (CRl) values, VM/SP maintains a queue of segment table origins (STO) and
associated shadow tables for the virtual machine. Thus, each time an MVS or SVS
system dispatches a new address space (changes CRl), VM/SP can dispatch the
proper shadow table.
Multiple shadow table support adds one control block to VM/SP, the segment
table origin control block (STOBLOK) pointed to by the ECBLOK. The
STOBLOK, created by DMKVAT, contains all information pertaining to the shad­
ow segment table, the shadow segment table itself and the virtual CRl value. It
also provides forward and backward queue pointers to the next STOBLOK on the
queue. The first STOBLOK on the queue always contains the shadow STO to be
loaded into CRl when the virtual machine is dispatched in translation mode. The
queue of STOBLOKs is maintained by DMKV AT in the following manner:
1. If a new CRl value is loaded by the virtual machine, then the queue of
STOBLOKs is searched for the virtual CRl value.
2. If the proper STO is found, then the STOBLOK is ordered first on the queue.
3. If the proper STO is not found, then the maximum STO count is checked.
4. If the number of STOBLOKs equals the maximum STO count, then the last STOBLOK is stolen, the shadow tables are purged, and the STOBLOK is reini­
tialized and reused by being chained first on the queue with the new virtual
CRl value.
5. If the number of STOBLOKs is less than the maximum STO count, then free
storage is obtained from VM/SP, and the STOBLOK is reinitialized and
chained first on the queue.
Multiple shadow table support is controlled by the SET STMUL TI command. The
default shadow table count is 3 and the maximum is 6 per virtual machine.
Shadow table bypass is controlled by the SET STBYP ASS command.
Performance Guidelines 35

Nott:: If virtual machine assist is enabled on the system, the virtual machine must
have the STFIRST directory option to be allowed to issue the SET STBYP ASS
nnM/ nnnnK command.
Shadow Table Bypass for the V=V User This technique is based on several characteristics of VS systems:
1. VS systems have a large area of addressing space starting with location zero
where the virtual address is equal to the real address.
2. This addressing space is common to each segment table when multiple segment
tables are used (MVS or SVS address space).
3. The VS system never pages within this fixed area.
Thus, an area starting with location zero can be established where the second-level
address equals the third-level address or virtual-virtual = virtual-real (VV = VR).
This allows a high-water mark, the highest VV = VR address, for a VS system to be
established. Because the second-level address is the same as the third-level
address, a reverse translation allows the shadow tables to be indirectly indexed.
Then, whenever VM/SP steals a page from the VV = VR area, it invalidates the
shadow page table entry and executes a real PTLB before redispatching the VS system's virtual machine.
In addition, whenever a shadow table is purged because a page frame is stolen from
above the high-water mark or the virtual machine executed a PTLB or LCTL, the
invalidation starts above the high-water mark, thus reducing purge and revalidation
time.
Shadow Table Bypass for the V=R User Queue Drop Elimination
By the use of a V =R shadow table bypass technique, both the shadow tables and
the overhead associated with maintaining them can be eliminated. This can be
accomplished by VM/SP modifying the virtual operating system's page table to
relocate virtual page zero to the highest real address within the V =R area. It is
then possible to dispatch the virtual machine pointing to its own page and segment
tables.
VM/SP attempts to optimize system throughput by monitoring the execution status
of virtual machines. When a virtual machine becomes idle, VM/SP drops it from
the active queue. The virtual machine's page and segment tables are scanned, and
resident pages are invalidated and put on the flush list.
VM/SP determines that a virtual machine is idle when it voluntarily suspends exe­
cution (by loading a virtual PSW with the wait state bit on, for example), and no
high-speed I/O operation is active. Normally, this is an adequate procedure.
However, in certain special cases, a virtual machine is determined to be idle and is
queue dropped, but it becomes active again sooner than expected. If this cycle of
queue dropping and reactivation is repeatedly executed, the overhead involved in
invalidating and revalidating the virtual machine's pages may become large.
The SNA VTAM service machine is an example of this special case. The VTAM
service machine operates by processing an IUCV message (or queue of messages),
36 VM/SP System Programmer's Guide