priocntl Usage

The priocntl(1) utility performs four different control interfaces on the scheduling of a process:

The following are some examples of using priocntl(1).

• The output of the -l option for the default configuration is:

  $ priocntl -l CONFIGURED CLASSES ================== SYS (System Class) TS (Time Sharing) Configured TS User Priority Range -60 through 60 RT (Real Time) Maximum Configured RT Priority: 59

• To display information on all processes:

  $ priocntl -d -i all

• To display information on all time-sharing processes:

  $ priocntl -d -i class TS

• To display information on all processes with user ID 103 or 6626:

  $ priocntl -d -i uid 103 6626

• To make the process with ID 24668 a real-time process with default parameters:

  $ priocntl -s -c RT -i pid 24668

• To make 3608 RT with priority 55 and a one-fifth second time slice:

  $ priocntl -s -c RT -p 55 -t 1 -r 5 -i pid 3608

• To change all processes into time-sharing processes:

  $ priocntl -s -c TS -i all

• To reduce TS user priority and user priority limit to -10 for uid 1122:

  $ priocntl -s -c TS -p -10 -m -10 -i uid 1122

• To start a real-time shell with default real-time priority:

  $ priocntl -e -c RT /bin/sh

• To run make with a time-sharing user priority of -10:

  $ priocntl -e -c TS -p -10 make bigprog

priocntl(1) includes the interface of nice(1). nice works only on time-sharing processes and uses higher numbers to assign lower priorities. The example above is equivalent to using nice(1) to set an increment of 10:

$ nice -10 make bigprog

priocntl Interface

priocntl(2) gets or sets the scheduling parameters of a process or set of processes much as the priocntl(1) utility does for a process. An invocation of priocntl(2) can act on a LWP, on a single process, or on a group of processes. A group of processes can be identified by parent process, process group, session, user, group, class, or all active processes. For more details, see the priocntl man page.

The PC_GETCLINFO command gets a scheduler class name and parameters when given the class ID. This command enables you to write programs that make no assumptions about what classes are configured.

The PC_SETXPARMS command sets the scheduler class and parameters of a set of processes. The idtype and id input arguments specify the processes to be changed.

Interactions With Other Interfaces

Altering the priority of a process in the TS class can affect the behavior of other processes in the TS class. This section identifies ways in which a scheduling change can affect other processes.

Kernel Processes

The kernel's daemon and housekeeping processes are members of the system scheduler class. Users can neither add processes to nor remove processes from this class, nor can they change the priorities of these processes. The command ps -cel lists the scheduler class of all processes. A SYS entry in the CLS column identifies processes in the system class when you run ps(1) with the -f option.

fork and exec

Scheduler class, priority, and other scheduler parameters are inherited across the fork(2) and exec(2) interfaces.

nice

The nice(1) command and the nice(2) interface work as in previous versions of the UNIX system. They enable you to change the priority of a time-sharing process. Use lower numeric values to assign higher time-sharing priorities with these interfaces.

To change the scheduler class of a process or to specify a real-time priority, use priocntl(2). Use higher numeric values to assign higher priorities.

init(1M)

Theinit(1M) process is a special case to the scheduler. To change the scheduling properties of init(1M), init must be the only process specified by idtype and id or by the procset structure.

Performance

Because the scheduler determines when and for how long processes run, this utility is of overriding importance to the performance and perceived performance of a system.

By default, all user processes are time-sharing processes. A process changes class only by a priocntl(2) call.

All real-time process priorities have a higher priority than any time-sharing process. As long as any real-time process is runnable, no time-sharing process or system process ever runs. A real-time application that occasionally fails to relinquish control of the CPU, can completely lock out other users and essential kernel housekeeping.

Besides controlling process class and priorities, a real-time application must also control other factors that affect its performance. The most important factors in performance are CPU power, amount of primary memory, and I/O throughput. These factors interact in complex ways. The sar(1) command has options for reporting on all performance factors.

Process State Transition

Applications that have strict real-time constraints might need to prevent processes from being swapped or paged out to secondary memory. A simplified overview of UNIX process states and the transitions between states is shown in the following figure.

Figure 3-2 Process State Transition Diagram

An active process is normally in one of the five states in the diagram. The arrows show how the process changes states.

• A process is running if it is assigned to a CPU. A process is removed from the running state by the scheduler if a process with a higher priority becomes runnable. A process is also pre-empted if it consumes its entire time slice and a process of equal priority is runnable.

• A process is runnable in memory if it is in primary memory and ready to run but is not assigned to a CPU.

• A process is sleeping in memory if it is in primary memory but is waiting for a specific event before it can continue execution. For example, a process sleeps while waiting for an I/O operation to complete, for a locked resource to be unlocked, or for a timer to expire. When the event occurs, a wakeup call is sent to the process. If the reason for its sleep is gone, the process becomes runnable.

• A process is runnable and swapped if it is not waiting for a specific event but has had its whole address space written to secondary memory to make room in primary memory for other processes.

• A process is sleeping and swapped if it is both waiting for a specific event and has had its whole address space written to secondary memory to make room in primary memory for other processes.

  If a machine does not have enough primary memory to hold all its active processes, that machine must page or swap some address space to secondary memory.

• When the system is short of primary memory, it writes individual pages of some processes to secondary memory but leaves those processes runnable. When a running process, accesses those pages, it sleeps while the pages are read back into primary memory.