When making changes to a configuration, the poold daemon acts on directions that you provide. You specify these directions as a series of constraints and objectives. The poold daemon uses your specifications to determine the relative value of different configuration possibilities in relation to the existing configuration. The daemon then changes the resource assignments of the current configuration to generate new candidate configurations.
Constraints affect the range of possible configurations by eliminating some of the potential changes that could be made to a configuration. The following constraints, which are specified in the libpool configuration, are available.
The minimum and maximum CPU allocations. See cpu.pinned Property Constraint.
The importance factor of the pool. See pool.importance Property Constraint.
Pinned components that are not available to be moved from a set. See pset.min Property and pset.max Property Constraints.
See the libpool(3LIB) man page and Pools Properties for more information about pools properties. See How to Set Pools Configuration Constraints for usage instructions.
The cpu-pinned property indicates that a particular CPU should not be moved by dynamic resource pools from the processor set in which it is located. You can set this libpool property to maximize cache utilization for a particular application that is executing within a processor set.
See Table 4, Defined Property Names for more details about this property.
The pool.importance property describes the relative importance of a pool as defined by the administrator.
These two properties place limits on the number of processors that can be allocated to a processor set, both minimum and maximum. See Table 4, Defined Property Names for more details about these properties.
Within these constraints, a resource partition's resources are available to be allocated to other resource partitions in the same Oracle Solaris instance. Access to the resource is obtained by binding to a pool that is associated with the resource set. Binding is performed at login or manually by an administrator who has the PRIV_SYS_RES_CONFIG privilege.
Objectives are specified similarly to constraints. The full set of objectives is documented in Table 4, Defined Property Names.
Objectives fall into two categories:
A workload-dependent objective is an objective that will vary according to the nature of the workload running on the system. An example is the utilization objective. The utilization figure for a resource set will vary according to the nature of the workload that is active in the set.
A workload-independent objective is an objective that does not vary according to the nature of the workload running on the system. An example is the CPU locality objective. The evaluated measure of locality for a resource set does not vary with the nature of the workload that is active in the set.
You can define three types of workload objectives.
|
Objectives are stored in property strings in the libpool configuration. The property names are as follows:
pset.poold.objectives
system.poold.objectives
Objectives have the following syntax:
objectives = objective [; objective]*
objective = [n:] keyword [op] [value]
All objectives take an optional importance prefix. The importance acts as a multiplier for the objective and thus increases the significance of its contribution to the objective function evaluation. The range is from 0 to INT64_MAX (9223372036854775807). If not specified, the default importance value is 1.
Some element types support more than one type of objective. An example is pset. You can specify multiple objective types for these elements. You can also specify multiple utilization objectives on a single pset element.
See How to Define Pools Configuration Objectives for usage examples.
The locality objective influences the impact that locality, as measured by locality group (lgroup) data, has upon the selected configuration. An alternate definition for locality is latency. An lgroup describes CPU and memory resources. The lgroup is used by the Oracle Solaris system to determine the distance between resources, using time as the measurement..
This objective can take one of the following three values:
If set, configurations that minimize resource locality are favored.
If set, the favorableness of a configuration is not influenced by resource locality. This is the default value for the locality objective.
If set, configurations that maximize resource locality are favored.
In general, the locality objective should be set to tight. However, to maximize memory bandwidth or to minimize the impact of DR operations on a resource set, you could set this objective to loose or keep it at the default setting of none.
The utilization objective favors configurations that allocate resources to partitions that are not meeting the specified utilization objective.
This objective is specified by using operators and values. The operators are as follows:
The 'less than' operator indicates that the specified value represents a maximum target value.
The 'greater than' operator indicates that the specified value represents a minimum target value.
The 'about' operator indicates that the specified value is a target value about which some fluctuation is acceptable.
A pset element can only have one utilization objective set for each type of operator.
If the ~ operator is set, then the < and > operators cannot be set.
If the < and > operators are set, then the ~ operator cannot be set. Note that the settings of the < operator and the > operator cannot contradict each other.
You can set both a < and a > operator together to create a range. The values will be validated to make sure that they do not overlap.
The wt-load objective favors configurations that match resource allocations to resource utilizations. A resource set that uses more resources will be given more resources when this objective is active. The wt-load objective name means "weighted load".
Use this objective when you are satisfied with the constraints you have established using the minimum and maximum properties, and you would like the daemon to manipulate resources freely within those constraints.
In the following example, the poold daemon is configured to assess these objectives for the pset:
The utilization should be kept between 30 percent and 80 percent.
The locality should be maximized for the processor set.
The objectives should take the default importance of 1.
pset.poold.objectives "utilization > 30; utilization < 80; locality tight"
See How to Define Pools Configuration Objectives for additional usage examples.
The poold daemon has four categories of properties:
Configuration
Constraint
Objective
Objective Parameter
|