Solaris Resource Manager 1.3 System Administration Guide

Technical Description

There are four attributes per lnode associated with the Solaris Resource Manager CPU scheduler: cpu.shares, cpu.myshares, cpu.usage, and cpu.accrue. The output of liminfo(1SRM) displays these attributes and other useful values.

Solaris Resource Manager scheduling is implemented using the SHR scheduling class. This includes support for the nice(1), priocntl(1), renice(1), and dispadmin(1M) commands. At the system-call level, SHR is compatible with the TS scheduling class.

A user's cpu.shares attribute is used to apportion CPU entitlement with respect to the user's parent and active peers. A user's cpu.myshares attribute is meaningful only if the user has child users who are active; it is used to determine the proportion of CPU entitlement with respect to them.

For example, if users A and B are the only children of parent P, and A, B, and P each have one share each within group P (that is, A and B have cpu.shares set to 1, while P has cpu.myshares set to 1), then they each have a CPU entitlement of one-third of the total entitlement of the group.

Thus, the actual CPU entitlement of a user depends on the parent's relative entitlement. This, in turn, depends on the relative values of cpu.shares of the parent to the parent's peers and to the cpu.myshares of the grandparent, and so on up the scheduling tree.

For system management reasons, processes attached to the root lnode are not subject to the shares attributes. Any process attached to the root lnode is always given almost all the CPU resources it requests.

It is important that no CPU-intensive processes be attached to the root lnode, since that would severely impact the execution of other processes. To avoid this, the following precautions should be taken:

The central administrator account should have its own UID, one that is different than the superuser account. This account should be used when logging in to perform non-administrative activities. If a UID of superuser is needed to carry out administrative functions, the central administrator can use the su(1) command to change UIDs while still keeping the account attached to its own lnode.
The srmuser(1SRM) command can be used in the init.d(4) scripts to attach any daemon processes to a non-root lnode. Any processes started in the boot script have, by default, an effective UID of root, and they are attached to the root lnode. The user command allows daemons to retain an effective UID of root, while attached to their own lnode. This will avoid problems if any of the daemons become CPU-intensive.

Not all group headers in the scheduling tree need to represent actual users who run processes, and in these cases it is not necessary to allocate them a share of CPU. Such lnodes can be indicated by setting their cpu.myshares attribute to zero. The cpu.accrue attribute in such a group header still includes all charges levied on all members of its group.

Allocated Share

The cpu.shares and cpu.myshares attributes determine each active lnode's current allocated share of CPU, as a percentage. The shares of inactive users make no difference to allocated share. If only one user is active, that user will have 100 percent of the available CPU resource. If there are only two active users with equal shares in the same group, each will have allocated shares of 50 percent. See Calculation of Allocated Share for more information on how the allocated share is calculated.

Usage and Decay

The cpu.usage attribute increases whenever a process attached to the lnode is charged for a CPU tick. The usage attribute value exponentially decays at a rate determined by the usage decay global Solaris Resource Manager parameter. The usage decay rate (described by a half-life in seconds) is set by the srmadm(1MSRM) command.

Although all processes have an lnode regardless of their current scheduling class, those outside the SHR scheduling class are never charged.

Accrued Usage

The accrued usage attribute increases by the same amount as the usage attribute, but is not decayed. It therefore represents the total accumulated usage for all processes that have been attached to the lnode and its members since the attribute was last reset.

Effective Share

An lnode's allocated share, together with its cpu.usage attribute, determines its current effective share. The Solaris Resource Manager scheduler adjusts the priorities of all processes attached to an lnode so that their rate of work is proportional to the lnode's effective share, and inversely proportional to the number of runnable processes attached to it.

Per-Process Share Priority (`sharepri`)

Each process attached to an lnode has internal data, specific to Solaris Resource Manager, that is maintained by the operating system kernel. The most important of these values for scheduling purposes is the sharepri value. At any time, the processes with the lowest sharepri values will be the most eligible to be scheduled for running on a CPU.