When a process is created, the system assigns a lightweight process (LWP) to the process. 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 a process can run. The scheduler maintains process priorities that are based on configuration parameters, process behavior, and user requests. The scheduler uses these priorities to determine which process runs next. The six priority classes are 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 dynamically adjusts process priorities to balance the response time of an interactive process. The policy also dynamically adjusts priorities to balance the throughput of a process that uses a lot of CPU time. The time-sharing class has the lowest priority.
The Oracle Solaris operating system (OS) scheduler also provides a real-time scheduling policy. Real-time scheduling enables users to assign fixed priorities to specific processes. The highest-priority real-time user process always gets the CPU as soon as the process is runnable.
The Oracle Solaris OS scheduler also provides a policy for fixed-priority scheduling. Fixed-priority scheduling enables users to assign fixed priorities to specific processes. Fixed-priority scheduling uses the same priority range as the time-sharing scheduling class by default.
A program can be written so that its real-time processes have a guaranteed response time from the system. For more information, see Real-time Programming and Administration.
The control of process scheduling provided by real-time scheduling is rarely needed. 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 – Displays or changes scheduler configuration in a running system. For more information, see the dispadmin(1M) man page.
A process inherits its scheduling parameters, including scheduling class and priority within that class, when the process is created. A process changes class only by a user request. The system adjusts the priority of a process based on user requests and the policy associated with the scheduler class of the process.
In a 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 can a process run. The scheduler always runs the runnable process with the highest global priority. A process assigned to the CPU runs until the process sleeps, uses its time slice, or is preempted by a higher-priority process. Processes with the same priority run 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.
Administrators specify default time slices in the configuration tables. Users can assign per-process time slices to real-time processes.
You can display the global priority of a process with –cl options of the ps command. You can display configuration information about class-specific priorities by using the priocntl command and the dispadmin command. For more information, see ps(1), priocntl(1), and dispadmin(1M) man pages.
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 the system 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. For example, a process sleeps when the process 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 time-sharing policy that is the default 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 preempts the running process.
Global process priorities and user-supplied priorities are in ascending order: 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 lower than the user priority limit. With appropriate permission, you can raise the user priority limit. Zero is the user priority limit by default.
You can lower the user priority of a process to reduce the CPU access of a process. Alternately, with the appropriate permission, you can raise the user priority to get faster service. The user priority cannot be set to a value that is higher than the user priority limit. Therefore, you must raise the user priority limit before raising the user priority if both have their default values at zero.
An administrator configures the maximum user priority independent of global time-sharing priorities. For example, in the default configuration a user can set a user priority in the -20 to +20 range. However, 60 time-sharing global priorities can be configured. For more information about configuring user priority, see the priocntl(1) man page.
The scheduler manages time-sharing processes by using configurable parameters in the time-sharing parameter table, ts_dptbl. This table contains information specific to the time-sharing class. For more information, see the ts_dptbl(4) man page.
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 cannot add a process to the system class. Users cannot remove a process from the system class. Priorities for system class processes are set up in the kernel code. The priorities of system processes do not change once established. User processes that run in kernel mode are not in the system class.
The real-time class uses a scheduling policy with fixed priorities 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) and priocntl(2) interfaces to assign real-time priorities. For more information, see the priocntl(1) or the priocntl(2) man pages.
The scheduler manages real-time processes by using configurable parameters in the real-time parameter table, rt_dptbl. This table contains information specific to the real-time class. For more information, see the rt_dptbl(4) man page.
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) to manage application performance by explicitly allocating shares of CPU resources to projects. A share indicates the allocation of CPU resources for a specific project. The system tracks resource usage over time. The system reduces the allocation when the usage of resources is heavy. The system increases allocation when the usage of resources is light. The FSS schedules CPU time among the 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. For more information, see the FSS(7) man page.
The FX class provides a fixed-priority preemptive scheduling policy. This policy is used by 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 by using configurable parameters in the fixed-priority dispatch parameter table, fx_dptbl. This table contains information specific to the fixed-priority class. For more information, see the fx_dptbl(4) man page.