Shares

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.