How Dynamic Resource Allocation Works
This section explains the process and the factors that poold uses to dynamically
About Available Resources
Available resources are considered to be all of the resources that are available
for use within the scope of the poold process. The scope of control
is at most a single Solaris instance.
On a system that has zones enabled, the scope of an executing
instance of poold is limited to the global zone.
Determining Available Resources
Resource pools encompass all of the system resources that are available for consumption
For a single executing Solaris instance, a resource of a single type, such
as a CPU, must be allocated to a single partition. There can
be one or more partitions for each type of resource. Each partition contains
a unique set of resources.
For example, a machine with four CPUs and two processor sets can
have the following setup:
pset 0: 0 1
pset 1: 2 3
where 0, 1, 2 and 3 after the colon represent CPU IDs.
Note that the two processor sets account for all four CPUs.
The same machine cannot have the following setup:
pset 0: 0 1
pset 1: 1 2 3
It cannot have this setup because CPU 1 can appear in only
one pset at a time.
Resources cannot be accessed from any partition other than the partition to which
To discover the available resources, poold interrogates the active pools configuration to find
partitions. All resources within all partitions are summed to determine the total amount
of available resources for each type of resource that is controlled.
This quantity of resources is the basic figure that poold uses in its
operations. However, there are constraints upon this figure that limit the flexibility that
poold has to make allocations. For information about available constraints, see Configuration Constraints.
Identifying a Resource Shortage
The control scope for poold is defined as the set of available resources
for which poold has primary responsibility for effective partitioning and management. However, other mechanisms
that are allowed to manipulate resources within this control scope can still affect
a configuration. If a partition should move out of control while poold is
active, poold tries to restore control through the judicious manipulation of available resources. If
poold cannot locate additional resources within its scope, then the daemon logs information
about the resource shortage.
Determining Resource Utilization
poold typically spends the greatest amount of time observing the usage of the
resources within its scope of control. This monitoring is performed to verify that
workload-dependent objectives are being met.
For example, for processor sets, all measurements are made across all of the
processors in a set. The resource utilization shows the proportion of time that
the resource is in use over the sample interval. Resource utilization is displayed
as a percentage from 0 to 100.
Identifying Control Violations
The directives described in Configuration Constraints and Objectives are used to detect the approaching failure of
a system to meet its objectives. These objectives are directly related to workload.
A partition that is not meeting user-configured objectives is a control violation. The
two types of control violations are synchronous and asynchronous.
A synchronous violation of an objective is detected by the daemon in the course of its workload monitoring.
An asynchronous violation of an objective occurs independently of monitoring action by the daemon.
The following events cause asynchronous objective violations:
Resources are added to or removed from a control scope.
The control scope is reconfigured.
The poold resource controller is restarted.
The contributions of objectives that are not related to workload are assumed to
remain constant between evaluations of the objective function. Objectives that are not related
to workload are only reassessed when a reevaluation is triggered through one of
the asynchronous violations.
Determining Appropriate Remedial Action
When the resource controller determines that a resource consumer is short of resources,
the initial response is that increasing the resources will improve performance.
Alternative configurations that meet the objectives specified in the configuration for the scope
of control are examined and evaluated.
This process is refined over time as the results of shifting resources are
monitored and each resource partition is evaluated for responsiveness. The decision history is
consulted to eliminate reconfigurations that did not show improvements in attaining the objective
function in the past. Other information, such as process names and quantities, are
used to further evaluate the relevance of the historical data.
If the daemon cannot take corrective action, the condition is logged. For more
information, see poold Logging Information.