sun.com docs.sun.com My Sun Worldwide Sites

Previous Previous     Contents     Index     Next Next
Chapter 6

Resource Pools

This chapter describes resource pools and their properties.

Overview of Resource Pools

Resource pools provide a framework for managing processor sets and thread scheduling classes. Resource pools are used for partitioning machine resources. Resource pools enable you to separate workloads so that workload consumption of certain resources does not overlap. The resource reservation helps to achieve predictable performance on systems with mixed workloads.

For an overview of resource pools and example commands for administering resource pools, see Chapter 12, "Resource Pools (Overview)," in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones and Chapter 13, "Creating and Administering Resource Pools (Tasks)," in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones.

A processor set groups the CPUs on a system into a bounded entity, on which a process or processes can run exclusively. Processes cannot extend beyond the processor set, nor can other processes extend into the processor set. A processor set enables tasks of similar characteristics to be grouped together and a hard upper boundary for CPU use to be set.

The resource pool framework allows the definition of a soft processor set with a maximum and minimum CPU count requirement. Additionally, the framework provides a hard-defined scheduling class for that processor set.

A zone can be bound to a resource pool through the pool property of the zone configuration. The zone is bound to the specified pool upon creation of the zone. The pool configuration can be changed only from the global zone. Zones cannot span multiple pools. All processes in a zone run in the same pool. However, multiple zones can bind to the same resource pool.

A resource pool defines:

  • Processor set groups

  • Scheduling class

Scheduling Class

Scheduling classes provide different CPU access characteristics to threads that are based on algorithmic logic. The scheduling classes include:

  • Realtime scheduling class

  • Interactive scheduling class

  • Fixed priority scheduling class

  • Timesharing scheduling class

  • Fair share scheduling class

For an overview of fair share scheduler and example commands for administering the fair share scheduler, see Chapter 8, "Fair Share Scheduler (Overview)," in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones and Chapter 9, "Administering the Fair Share Scheduler (Tasks)," in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones.

Do not mix scheduling classes in a set of CPUs. If scheduling classes are mixed in a CPU set, system performance might become erratic and unpredictable. Use processor sets to segregate applications by their characteristics. Assign scheduling classes under which the application best performs. For more information about the characteristics of an individual scheduling class, see priocntl(1).

For an overview of resource pools and a discussion of when to use pools, see Chapter 6, Resource Pools.

Dynamic Resource Pool Constraints and Objectives

The libpool library defines properties that are available to the various entities that are managed within the pools facility. Each property falls into the following categories:

Configuration constraints

A constraint defines boundaries of a property. Typical constraints are the maximum and minimum allocations specified in the libpool configuration.

Objective

An objective changes the resource assignments of the current configuration to generate new candidate configurations that observe the established constraints. An objective has the following categories:

Workload dependent

A workload-dependent objective varies according to the conditions imposed by the workload. An example of the workload dependent objective is the utilization objective.

Workload independent

A workload-independent objective does not vary according to the conditions imposed by the workload. An example of the workload independent objective is the cpu locality objective.

An objective can take an optional prefix to indicate the importance of the objective. The objective is multiplied by this prefix, which is an integer from 0 to INT64_MAX,, to determine the significance of the objective.

For usage examples, see "How to Set Configuration Constraints" in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones and "How to Define Configuration Objectives" in System Administration Guide: Solaris Containers-Resource Management and Solaris Zones.

System Properties

system.bind-default (writable boolean)

If the specified pool is not found in <filename>/etc/project</filename>, bind to pool with the pool.default property set to TRUE.

system.comment (writable string)

User description of system. system.comment is not used by the default pools commands, except when a configuration is initiated by the poolcfg utility. In this case, the system puts an informative message in the system.comment property for that configuration.

system.name (writable string)

User name for the configuration.

system.version (read-only integer)

libpool version required to manipulate this configuration.

Pools Properties

All pools properties except pool.default and pool.sys_id are writable.

pool.active (writable boolean)

If TRUE, mark this pool as active.

pool.comment (writable string)

User description of pool.

pool.default (read-only boolean)

If TRUE, mark this pool as the default pool. See the system.bind-default property.

pool.importance (writable integer)

Relative importance of this pool. Used for possible resource dispute resolution.

pool.name (writable string)

User name for pool. setproject(3PROJECT) uses pool.name as the value for the project.pool project attribute in the project(4) database.

pool.scheduler (writable string)

Scheduler class to which consumers of this pool are bound. This property is optional and if not specified, the scheduler bindings for consumers of this pool are not affected. For more information about the characteristics of an individual scheduling class, see priocntl(1). Scheduler classes include:

  • RT for realtime scheduler

  • TS for timesharing scheduler

  • IA for interactive scheduler

  • FSS for fair share scheduler

  • FX for fixed priority scheduler

pool.sys_id (read-only integer)

This is the system-assigned pool ID.

Previous Previous     Contents     Index     Next Next
Company Info Contact Terms of Use Privacy Copyright 1994-2007 Sun Microsystems, Inc.