vparresources2.5 (2012 03)

v
vparresources2(5) vparresources2(5)
(For OA Based Partition Management Systems)
[CPU Details]
Min/Max: 0/16
User assigned [Path]: 3/1/0/2
Boot processor [Path]: 3/1/0/2
System assigned [Path]: 3/1/0/0
3/1/0/1
3/1/0/3
3/1/1/0
3/2/0/0
3/2/0/1
Non-socket-specific:
User assigned [Count]: 1
System assigned [Count]: 4
Socket-specific [Count]: Socket-ID/Count
3/2/0 2
Note that in the path displays, the user assigned CPU-core is also the boot processor, and so has been
shown in the Boot processor line.
The boot processor is meaningful only when a vPar is running. When a vPar is
DOWN, the
Boot pro-
cessor
line is empty.
The Boot Processor
The boot processor is the first processor to be activated when the vPar is booted, and is the one on which
all boot time activity takes place. This responsibility is assigned by the system.
Multiple-Core CPU Sockets
Certain designs of CPUs are fabricated such that they share common low-level hardware. Each such
CPU is termed a core. The set of common hardware that they share is termed a socket. CPU-cores that
share a socket are called siblings. In a vPars environment, each CPU-core is managed as a separate
resource. So, it is possible to assign siblings to different virtual partitions. The system will attempt to
assign siblings to the same vPar whenever possible.
Further discussion of multiple-core CPU sockets is beyond the scope of this manpage. However, the
vparstatus -d command will display any sibling relationship that might exist.
CPU States
The platform support for CPU diagnostics includes CPU diagnostic tools running in the background.
Their purpose is to detect incipient errors in CPU hardware. As part of this operation, they manage
several co-existing CPU states:
OK, Indict, Deconf, Parent Indict, Parent Deconf
. These
states are displayed by the
vparstatus -d command. Detailed descriptions of these states are beyond
the scope of this manpage, but their effects on vPars configuration/operation are described next.
Deconfigured CPU-cores are not activated in a vPar. Any CPU-cores scheduled for deconfiguration are
not activated at the next vPar boot. CPU-cores having its container or parent resource (socket, blade etc.)
deconfigured is also not considered for activation in a vPar.
A vPar is booted if there are enough healthy CPU-cores available to boot the vPar. Since deconfigured
CPU-cores are not used, user specified requirements for vPar CPU-core assignment may not be met in
some cases. The vPar database information is appropriately modified to reflect the actual CPU-core
assignments given to the vPar. If the user does not want the vPar database information to be modified,
they should disable the parspec change policy attribute for the nPartition. In that case, if CPU-core
requirements specified by the user cannot be met because of unavailability of CPU-cores, booting of the
vPars is not allowed and the vPar configuration in the vPar database is left unmodified.
Indicted or parent-indicted CPU-cores are still considered for activation at boot time. Only if they actu-
ally get deconfigured or scheduled for deconfiguration, they are excluded from activation.
Memory
SLM and ILM
There are two major types of memory designation, Socket Local Memory, (SLM), and InterLeaved
Memory, (ILM). With SLM, entire memory address ranges are from a single socket. For best perfor-
mance these ranges should be on the same socket as the CPU cores. ILM is an address range of memory
whose adjacent addresses reside on one or more sockets in the underlying nPartition. In this topic, we
describe the mechanics of managing each memory type.
4 Hewlett-Packard Company − 4 − HP-UX 11i Version 3: March 2012