vparresources.5 (2010 09)

v
vparresources(5) vparresources(5)
[CPU Details]
Min/Max: 1/8
User assigned [Path]:
Boot processor [Path]: 0.12
Monitor assigned [Path]: 2.10
2.11
2.12
3.10
3.11
Non-cell-specific:
User assigned [Count]: 1
Monitor assigned [Count]: 3
Cell-specific [Count]: Cell ID/Count
32
Note that in the path displays, the user assigned CPU is also the boot processor, and so has been shown
in the Boot processor line rather than the
User assigned line.
The boot processor is meaningful only when a vPar is running. When a vPar is
Down or in an alternate
database, the
Boot processor line or -M
subfield 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. It is assigned this responsibility by the vPar monitor. Due to the spe-
cial requirements of the boot processor in an OS, it cannot be deleted while the vPar is running. Each
vPar OS assigns a processor number of zero for its boot processor irrespective of the processor’s hardware
path or what its processor number would have been if the OS had booted in the nPartition.
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. CPUs that
share a socket are called siblings. In a vPars environment, each CPU is managed as a separate
resource. So, it is possible to assign siblings to different virtual partitions. The vPars monitor 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 Migration
CPUs that are added to or deleted from a running vPar undergo a process termed CPU Migration. This
is the period between when the configuring vPar’s command terminates and the operation is actually com-
plete. When adding a CPU, the CPU must undergo a short setup period during which supporting
low-level resources are added and activated in the vPar. It is then placed on the kernel’s list of active
processors so that work may be scheduled on it. At this point, migration in is complete.
A CPU to be deleted is normally performing useful activity for its vPar. Before the CPU can be released
to the monitor, making it available for assignment to other virtual partitions, this activity must be ter-
minated in an orderly fashion. When this process is finished, migration out is complete.
In terms of vPars assignment, a CPU is removed from the monitor’s Available list and assigned to a run-
ning vPar by the
vparmodify command. It is assigned throughout the migration in period. When
deleting a CPU from a vPar the CPU remains assigned to the vPar until migration out is complete.
The various forms of the
vparstatus command (summary, detailed, machine-readable) indicate CPUs
undergoing migration in or out. Refer to the vparstatus (1M) manpage for details.
CPU States
Every HP-UX operating system includes CPU diagnostics which run 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:
Enabld, Inactv, Failed, MarkDC. 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.
vPars does not allow the boot processor to enter the
Inactv or Failed state. This is because any CPU
in a running vPar that enters either of these states is not allowed to continue processing beyond the time
4 Hewlett-Packard Company − 4 − HP-UX 11i Version 3: September 2010