HP Virtual Server Environment: Tips for Application Developers

How Resource Migrations Work
Let’s take a look at how core migrations work in the different types of partitions. For this discussion,
we separate out the whole core granularity partitions from the sub-core granularity partitions.
Whole core Granularity Partitions
This section covers partitions that allocate whole cores. In these partition types the number of cores
that are visible to an application can vary. All core activations, deactivations and migrations are
handled by the core scheduler in the HP-UX kernel and will be transparent to most applications. The
scheduler will simply move some of the active processes and threads to the new cores when they are
activated and remove the processes and threads before the cores are deactivated. As a result, this
section is relevant only if the application queries the system to determine how many cores are present
and then takes some action based on that number. Later we will provide a recommendation of a
function call that can be used to determine the number of cores that are present in any of these
partitions.
nPars
Changing the core count in an nPar is implemented via CPU Instant Capacity activation and
deactivation. This can be done in several ways: (1) Dynamic Processor Resilience; (2) Core
Migration between nPars via iCAP or Global iCAP; (3) Activation of Temporary Capacity; or (4)
Permanent iCAP activation. In all these cases, HP-UX is notified of all physical processors available at
boot time. The iCAP software then deactivates unlicensed processors. These processors can be
activated, or deactivated, as needed using the mechanisms described above.
vPars
Virtual Partitions provide the ability to migrate a single core from one vPar to another, while both
partitions are running and are under load. During the hardware discovery phase of HP-UX bootup,
the vPar monitor presents to the OS in the vPar all cores that it may ever be able to see. This
includes Instant Capacity cores that are not activated as well as all the cores that are not permanently
bound to another vPar. This ensures that the OS has configuration information for all the cores that it
may ever activate.
Cores can be de-activated from a vPar using the ‘vparmodify –d’ command. This returns the core to
the vPar monitor for assignment. Cores can be activated in a vPar by the vPar monitor using the
‘vparmodify –a’ command. Cores can also be activated in a vPar via all the mechanisms described
under nPars (above). Core migration is accomplished via a de-activate operation on a donor vPar
followed by an activate operation on the recipient vPar. So, while all the cores that can be used by a
vPar will be visible in an ioscan, it is possible that only a subset of them will actually be active in the
vPar at any point in time. The vPar monitor is responsible for enforcing that each core is active in at
most one vPar at any given time.
Resource Partitions based on Processor Sets
A Processor Set (pset) is implemented by instantiating separate process schedulers for each pset.
Each pset is then assigned a set of processors and processes that are to be scheduled on the run
queues of those processors. Psets can be configured using the psrset command, although, for
usability reasons, it is recommended that the PRM product be used to configure psets in a production
environment. See prm(1) for details.
Cores assigned to psets are taken from the default pset. Cores removed from psets are returned to the
default pset. Core migration between psets is accomplished by de-allocating a core from one pset
and subsequently allocating it to another. This is a “normal” operation for psets, because the initial