|
NAME : HCPVMUBK
DESCRIPTION: Virtual Machine CPU Usage block
DSECT : VMUBK
FUNCTION : Contains the data necessary to track CPU usage by a
particular virtual CPU and then to predict its future
CPU usage in the next interval. The prediction is used
as part of the algorithm in the work load rebalance
routine when it is deciding to which dispatch vector the
VMDBK should be assigned.
LOCATED BY : The pointer VMDVMUBK in each VMDBK and one of the
RCCVMUOA or RCCVMUUA arrays of VMUBKs during rebalance
CREATED BY : HCPBVMBK at logon or relocation time
DELETED BY : HCPALLFG or HCPSTLDT at logoff time or DETACH CPU
REFERENCES : None
SERIALIZED : This control block is only used by the thread that is
called once every two seconds to do work load rebalancing.
That thread is HCPHIPTM, the Periodic HiperDispatch Routine.
It includes execution of a work load rebalance routine.
The rebalance is done in two steps. First, the CPU usage
of all VMDBKs in the system during the previous interval
is calculated and stored in the VMDBK's VMUBK. This first
step also builds two arrays of origin VMUBKs: an ordered
array (RCCVMUOA) and an unordered array (RCCVMUUA). The
RCCVMUOA array is ordered by total predicted CPU usage
of the guest. The second step is the actual rebalance
operation which occurs in a later part of the Periodic
HiperDispatch Routine.
The Periodic HiperDispatch Routine can only run on one
processor at a time because the timer to schedule the
next invocation is not set until the thread completes.
When the VMUBK arrays are built during the first step of
rebalance, the RCCVMULK lock is obtained. It is held
until the actual rebalance completes in the second part
of the rebalance operation. That means this lock is
obtained near the beginning of the Periodic HiperDispatch
routine and is held until rebalance is complete.
The RCCVMULK lock is obtained early in the rebalance
process so that the RCCVMUOA and RCCVMUUA arrays can be
built without holding the scheduler lock. However, the
scheduler lock is required for the actual rebalancing.
Because of this, the RCCVMULK lock must be obtained
before the vary on, scheduler, and topology locks.
The only other times a VMUBK is referenced is when it is
obtained or released, or during the monitor sampling
process. Obtain is done at logon before any other
process can access the block. Release of an origin
VMDBK's VMUBK is done under protection of the RCCVMULK
and thus cannot happen until the rebalance thread is done.
A virtual MP's (or adjunct's) VMUBK is not released until
an MP delay is done similar to how a vMP VMDBK is released.
Since the vMP VMUBK is only accessed during rebalance scan
of the RCCVMUOA and RCCVMUUA arrays and since there is no
loss of control during that scan, the MP delay stops the
logoff code in HCPSTLDT from releasing the vMP VMUBK until
after the rebalance function is done with the array scan
without requiring the RCCVMULK lock. This is necessary
because HCPSTLDT runs under protection of the scheduler
lock and obtaining the RCCVMULK during that routine would
violate the lock heirarchy. The monitor references to
the VMUBK are protected in the same manner that its
references to the vMP VMDBK are serialized.
RELOCATION CONSIDERATIONS : This control block is associated with a virtual CPU but
it is not relocated along with the virtual machine.
Instead, on the relocation destination system, a new
instance is created and initialized as it would be at
logon time.
COMPATIBILITY AND MIGRATION CONCERNS : None
NOTES : 1) All fields that contain CPU usage values are expressed
as a percentage of a CPU scaled by x'10000'. So a
usage of half of a CPU would be kept as x'8000' and
usage of one and a half CPUs would be x'18000'.
| |