This chapter describes the scheduling of processes and how to modify scheduling.
"Overview of the Scheduler" contains an overview of the scheduler and the time-sharing scheduling class. Other scheduling classes are briefly described.
"Commands and Interfaces " describes the commands and interfaces that modify scheduling.
"Interactions With Other Interfaces " describes the effects of scheduling changes on kernel processes and certain interfaces.
Performance issues to consider when using these commands or interfaces are covered in "Performance ".
The chapter is for developers who need more control over the order of process execution than default scheduling provides. See Multithreaded Programming Guide for a description of multithreaded scheduling.
Overview of the Scheduler
When a process is created, the system assigns a lightweight process (LWP) to it. If the process is multithreaded, more LWPs might be assigned to the process. An LWP is the object that is scheduled by the UNIX system scheduler, which determines when processes run. The scheduler maintains process priorities based on configuration parameters, process behavior, and user requests. It uses these priorities to determine which process runs next. There are six priority classes: real-time, system, interactive (IA), fixed-priority (FX), fair-share (FSS), and time-sharing (TS).
The default scheduling is a time-sharing policy. This policy adjusts process priorities dynamically to balance the response time of interactive processes and the throughput of processes that use a lot of CPU time. The time-sharing class has the lowest priority.
The SunOS 5.9 scheduler also provides a real-time scheduling policy. Real-time scheduling enables the assigning of fixed priorities to specific processes by users. The highest-priority real-time user process always gets the CPU as soon as the process is runnable .
The SunOS 5.9 scheduler also provides a fixed-priority scheduling policy. Fixed-priority scheduling enables the assignment of fixed priorities to specific processes by users. By default, this scheduling policy uses the same priority range as the time-sharing scheduling class.
A program can be written so that its real-time processes have a guaranteed response time from the system. See Chapter 9, Real-time Programming and Administration for detailed information.
The control of process scheduling provided by real-time scheduling is rarely needed and can cause more problems than it solves. However, when the requirements for a program include strict timing constraints, real-time processes might be the only way to satisfy those constraints.
Caution - Careless use of real-time processes can have a dramatic negative effect on the performance of time-sharing processes.
Because changes in scheduler administration can affect scheduler behavior, programmers might also need to know something about scheduler administration. The following interfaces affect scheduler administration:
dispadmin(1M) displays or changes scheduler configuration in a running system.
ts_dptbl(4) and rt_dptbl(4) are tables containing the the time-sharing and real-time parameters that are used to configure the scheduler.
A process inherits its scheduling parameters, including scheduling class and priority within that class, when it is created. A process changes class only by user request. The system manages the priority of a process based on user requests and the policy associated with the scheduler class of the process.
In the default configuration, the initialization process belongs to the time-sharing class. Therefore, all user login shells begin as time-sharing processes.
The scheduler converts class-specific priorities into global priorities. The global priority of a process determines when it runs. The scheduler always runs the runnable process with the highest global priority. Numerically higher priorities run first. When the scheduler assigns a process to the CPU, the process runs until it sleeps, uses its time slice, or is pre-empted by a higher-priority process. Processes with the same priority run round-robin (in sequence, around a circle).
All real-time processes have higher priorities than any kernel process, and all kernel processes have higher priorities than any time-sharing process.
Note - As long as there is a runnable real-time process in a single processor system, no kernel process and no time-sharing process runs.
Administrators specify default time slices in the configuration tables and users can assign per-process time slices to real-time processes.
You can display the global priority of a process with the -cl options of the ps(1) command. You can display configuration information about class-specific priorities with the priocntl(1) command and the dispadmin(1M) command.
The following sections describe the scheduling policies of the six scheduling classes.
The goal of the time-sharing policy is to provide good response time to interactive processes and good throughput to CPU-bound processes. The scheduler switches CPU allocation often enough to provide good response time, but not so often that it spends too much time on switching. Time slices are typically a few hundred milliseconds.
The time-sharing policy changes priorities dynamically and assigns time slices of different lengths. The scheduler raises the priority of a process that sleeps after only a little CPU use. A process sleeps, for example, when it starts an I/O operation such as a terminal read or a disk read. Frequent sleeps are characteristic of interactive tasks such as editing and running simple shell commands. The time-sharing policy lowers the priority of a process that uses the CPU for long periods without sleeping.
The default time-sharing policy gives larger time slices to processes with lower priorities. A process with a low priority is likely to be CPU-bound. Other processes get the CPU first, but when a low-priority process finally gets the CPU, that process gets a larger time slice. If a higher-priority process becomes runnable during a time slice, however, the higher-priority process pre-empts the running process.
Global process priorities and user-supplied priorities are in ascending order: numerically higher priorities run first. The user priority runs from the negative of a configuration-dependent maximum to the positive of that maximum. A process inherits its user priority. Zero is the default initial user priority.
The "user priority limit" is the configuration-dependent maximum value of the user priority. You can set a user priority to any value below the user priority limit. With appropriate permission, you can raise the user priority limit. Zero is the default user priority limit.
You can lower the user priority of a process to give the process reduced access to the CPU or, with the appropriate permission, raise the user priority to get faster service. Because you cannot set the user priority above the user priority limit, you must raise the user priority limit before you raise the user priority if both have their default values at zero.
An administrator configures the maximum user priority independent of global time-sharing priorities. In the default configuration, for example, a user can set a user priority only in the range from -20 to +20, but 60 time-sharing global priorities are configured.
The system class uses a fixed-priority policy to run kernel processes such as servers and housekeeping processes like the paging daemon. The system class is reserved to the kernel. Users can neither add a process to the system class nor remove one from it. Priorities for system class processes are set up in the kernel code. Once established, the priorities of system processes do not change. User processes running in kernel mode are not in the system class.
The real-time class uses a fixed-priority scheduling policy so that critical processes run in predetermined order. Real-time priorities never change except when a user requests a change. Privileged users can use the priocntl(1) command or the priocntl(2) interface to assign real-time priorities.
The scheduler manages real-time processes using configurable parameters in the real-time parameter table rt_dptbl(4). This table contains information specific to the real-time class.
The IA class is very similar to the TS class. When used in conjunction with a windowing system, processes have a higher priority while running in a window with the input focus. The IA class is the default class while the system runs a windowing system. The IA class is otherwise identical to the TS class, and the two classes share the same ts_dptbl dispatch parameter table.
The FSS class is used by the Fair-Share Scheduler (FSS(7)) to manage application performance by explicitly allocating shares of CPU resources to projects. A share indicates a project's entitlement to available CPU resources. The system tracks resource usage over time, reducing entitlement for heavy usage and increasing it for light usage. The FSS schedules CPU time among processes according to their owners' entitlements, independent of the number of processes each project owns. The FSS class uses the same priority range as the TS and IA classes. See the FSS man page for more details.
The FX class provides a fixed-priority pre-emptive scheduling policy for processes that require user or application control of scheduling priorities but are not dynamically adjusted by the system. By default, the FX class has the same priority range as the TS, IA, and FSS classes. The FX class allows user or application control of scheduling priorities through user priority values assigned to processes within the class. These user priority values determine the scheduling priority of a fixed-priority process relative to other processes within its class.
The scheduler manages fixed-priority processes using configurable parameters in the fixed-priority dispatch parameter table fx_dptbl(4). This table contains information specific to the fixed-priority class.
Commands and Interfaces
The figure below illustrates the default process priorities.
Figure 3-1 Process Priorities (Programmer's View)
A process priority has meaning only in the context of a scheduler class. You specify a process priority by specifying a class and a class-specific priority value. The class and class-specific value are mapped by the system into a global priority that the system uses to schedule processes.
A system administrator's view of priorities is different from that of a user or programmer. When configuring scheduler classes, an administrator deals directly with global priorities. The system maps priorities supplied by users into these global priorities. See System Administration Guide: Basic Administration for more information about priorities.
The ps(1) command with -cel options reports global priorities for all active processes. The priocntl(1) command reports the class-specific priorities that users and programmers use.
The priocntl(1) command and the priocntl(2) and priocntlset(2) interfaces set or retrieve scheduler parameters for processes. Setting priorities generally follows the same sequence for the command and both interfaces:
Specify the target processes.
Specify the scheduler parameters you want for those processes.
Execute the command or interface to set the parameters for the processes.
Process IDs are basic properties of UNIX processes (see Intro(2)). The class ID is the scheduler class of the process. priocntl(2) works only for the time-sharing and the real-time classes, not for the system class.