Process scheduling

In UnixWare, the schedulable entity is always a lightweight process (LWP). Scheduling priorities and classes are attributes of LWPs and not processes. When scheduling system calls accept a process on which to operate, the operation is applied to each LWP in the process. The UNIX system scheduler determines when LWPs run. It maintains priorities based on configuration parameters, process behavior, and user requests; it uses these priorities to assign LWPs to the CPU.

UnixWare gives users absolute control over the sequence in which certain LWPs run, and the amount of time each LWP may use the CPU before another LWP gets a chance.

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.

The scheduler offers a fixed priority scheduling policy as well as a time-sharing policy. Fixed priority scheduling allows users to set fixed priorities on a per-process or LWP basis. 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 may also be written so that its fixed priority LWPs have a guaranteed response time from the system.

For most UNIX environments, the default scheduler configuration works well and no fixed priority LWPs are needed: administrators 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.

You can manage the relationship between processes and processors. 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 section is addressed to programmers who need more control over order of process and LWP execution than they get using default scheduler parameters.

Because changes in scheduler administration can affect scheduler behavior, programmers may also need to know about scheduler administration. There are a few reference manual entries with information on scheduler administration:

• dispadmin(1M) tells how to change scheduler configuration in a running system.

• ts_dptbl(4), fc_dptbl(4), and fp_dptbl(4) describe the time-sharing, fixed class, and fixed priority parameter tables that are used to configure the scheduler.

The rest of this section is organized as follows:

• ``How the process scheduler works'' describes what the scheduler does and how it does it. It also introduces scheduler classes.

• ``Scheduler commands and function calls'' describes and gives examples of the priocntl(1) command and the priocntl(2), priocntllist(2), and priocntlset(2) system calls, the user interface to scheduler services. The priocntl functions allow you to retrieve scheduler configuration information and to get or set scheduler parameters for a process or LWP, or a set of processes or LWPs.

• ``Scheduler interaction with other functions'' describes the interactions between the scheduler and related functions.

• ``Scheduler performance'' discusses scheduler latencies of which some applications must be aware, and mentions some considerations other than the scheduler that application designers must take into account to ensure that their requirements are met.

• ``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.