Scheduling and System Performance
The scheduler determines when and for how long processes run. Therefore, the behavior of the scheduler strongly affects system performance.
By default, all user processes are time-sharing processes. A process changes class only by a priocntl() call.
All real-time process priorities have a higher priority than any time-sharing process. Time-sharing processes or system processes cannot run while any real-time process is runnable. 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 command has options for reporting on all performance factors. For information about sar command, see the sar(1) man page and for information about priocntl() call, see the priocntl(2) man page.
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 2 Process State Transition Diagram
An active process is can be one of the five states in the diagram. The arrows show how the process changes states.
-
A process is running if the process is assigned to a CPU. A process is removed from the running state by a scheduler if a process with a higher priority becomes runnable. A process is also preempted if a process of equal priority is runnable when the original process consumes its entire time slice.
-
A process is runnable in memory if the process is in primary memory and ready to run, but is not assigned to a CPU.
-
A process is sleeping in memory if the process is in primary memory but is waiting for a specific event before continuing 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 and the process becomes runnable.
-
When an address space of a process has been written to the secondary memory, and that process is not waiting for a specific event, the process is runnable and swapped.
-
If a process is waiting for a specific event and has its whole address space written to the secondary memory, the process is sleeping and swapped.
If a system does not have enough primary memory to hold all its active processes, that system must page or swap some address space to the secondary memory.
-
When the system is short of primary memory, the system writes individual pages of some processes to the secondary memory but leaves those processes runnable. When a running process, accesses those pages, the process sleeps while the pages are read back into primary memory.
-
When the system encounters a more serious shortage of primary memory, the system writes all the pages of some processes to secondary memory. The system marks the pages that have been written to the secondary memory as swapped. Such processes can only be scheduled when the system scheduler daemon selects these processes to be read back into memory.
Both paging and swapping cause delay when a process is ready to run again. For processes that have strict timing requirements, this delay can be unacceptable.
To avoid swapping delays, real-time processes are never swapped, though parts of such processes can be paged. A program can prevent paging and swapping by locking its text and data into primary memory. For more information, see the memcntl(2) man page. How much memory can be locked is limited by how much memory is configured. Also, locking too much can cause intolerable delays to processes that do not have their text and data locked into memory.
Trade-offs between the performance of real-time processes and the performance of other processes depend on local needs. On some systems, process locking might be required to guarantee the necessary real-time response.
For more information about latencies in real-time applications, see Dispatch Latency.