Process scheduling

By default, the scheduler uses a time-sharing policy similar to the policy used in previous releases. A time-sharing policy adjusts priorities dynamically in an attempt to provide good response time to interactive LWPs and good throughput to CPU-intensive LWPs. A fixed class policy is now available that is similar to the time-sharing policy except that it does not adjust priorities.

The scheduler also offers a fixed priority scheduling policy. Fixed priority scheduling, previously known as real-time scheduling, allows users to set fixed priorities on a per-process or LWP basis. In the default configuration, the highest-priority fixed priority LWP always gets the CPU as soon as it is runnable, even if system processes are runnable. An application can therefore specify the exact order in which LWPs run. An application also can be written so that its fixed priority LWPs have a guaranteed response time from the system.

Users can have absolute control over the sequence in which certain LWPs run, and the amount of time each LWP can use the CPU before another LWP can use the CPU.

For most environments, the default scheduler configuration works well and no fixed priority LWPs are needed; you should not change configuration parameters and users should not change scheduler properties of their applications. However, for some applications with strict timing constraints, fixed priority LWPs are the only way to guarantee that the application's requirements are met.

Administrators can manage the relationship between processes and processors. Processors can be taken offline or brought online. Processes can be bound to a specific processor and processors can be bound exclusively by a process. Note that exclusive binding applies only to user-level processes and not to kernel drivers. That is, the exclusive binding of a user-level process excludes other user level processes, but not a kernel driver.

This topic is addressed to administrators who need to adjust the default configuration for the scheduler. You should understand the scheduler for these reasons:

• The scheduler has an overriding effect on the performance and perceived performance of a system. The default scheduler is tuned to perform well in representative work environments; therefore, you must understand how it operates to know whether you can reconfigure it to better suit local needs.

• A bug in a fixed priority program or a malicious fixed priority user can lock out all other processing, including kernel processing. Users need privilege to create fixed priority processes, and presumably only trustworthy users have this privilege. But you still must be aware that the scheduler functions introduce new ways to cause trouble and should be prepared for accidents and for misuse of these functions.

The rest of this topic is organized as follows:

• The ``Overview of the process scheduler'' tells what the scheduler does and how it does it. It also introduces scheduler classes.

• ``Configuring the scheduler'' describes how you can control the scheduler using tunable parameters and the scheduler parameter tables: ts_dptbl(4) for time-sharing parameters, fp_dptbl(4) for fixed priority parameters, and fc_dptbl(4) for fixed class parameters.

• ``Changing scheduler parameters with dispadmin'' tells how to display or change scheduler parameters in a running system. These dispadmin changes do not survive a reboot. To make permanent changes in scheduler configuration, use idtune(1M) to change the scheduler parameter tables in the /etc/conf/mtune.d files.

• ``Managing processors and processes'' describes how you can manage the relationship between processors and processes. It tells how you can take processors offline or bring them online. You also can bind processes to processors.