You can think of the process control system as containing the kernel's scheduling subsystem, memory management subsystem, and interprocess communication (IPC) subsystm.
The process control system interacts with the file system when reading files into memory before executing them. Several processes may be instances of the same program; for example, more than one person might be using vi at same time; each invocation of vi is an instance of the same process.
A process reads and writes its own data and stack, but cannot write/read any other processes'. (Note, however, shared memory can be read and written by several processes.)
Processes communicate with other processes via shared memory or system
calls. Communication between processes (IPC) includes asynchronous signaling 5 of events and synchronous transmission of messages between processes. System
calls are requests by a process for some service from the kernel, such as I/O, process coordination, system status, and data exchange. All HP -UX system calls are documented in section 2 of HP- UX Reference Manual.
Much valuable information about CPU usage can be obtained by running monitor or top from the Process Management area of SAM.
Process Modes
An HP- UX process can execute in two modes-kernel or user mode-and through its process lifetime, switches between them. Information about the process (such as variables, process addresses, buffer counts) accumulates in a
"stack" for each mode, and it is through these stacks that the process executes instructions and switches modes.
For Series 300/400, certain kinds of instructions trigger mode changes; for eXcc!!lple; wbpn a program invokes a system call~ an entry point in the system call library is encoded in assembly language and contains "trap" instructions, which, when executed, cause an interrupt that results in a switch to kernel mode. When the process executes the instruction, it switches mode to the kernel, executes kernel code, and uses the kernel stack.
Process Management 5-17
For Series 700/800, when you make a system call, you go through system call stub code, which passes the system call number through a gateway page that adjusts privilege bits to put the process in kernel mode.
Every process has an entry in a kernel process table and a u_area structure, which contains private data such as control and status information. The context of a process is defined by all the unique elements identifying it-the contents of its user and kernel stacks, values of its registers, data structures, and variables.
Although HP- UX gives the illusion of executing multiple processes
simultaneously, each CPU actually executes one process at a time, according to its priority. (In multiprocessing systems, several SPU s can be executing a process simultaneously.)
The principle behind the distribution of CPU time is called time-slice-the 5 amount of time a process can run before the kernel checks to see if there is an
equal-priority process ready to run.
Process Priorities
Processes are chosen by the scheduler to execute a time-slice based on their priority. Priorities range from 0 (highest priority) to 256 (lowest priority), and are classified by need. You can see at what priority a process is set to run at by looking in the PRI column when you invoke ps or top. The following lists the three categories of priority:
Real- time priority (0-127) System priority (128-177) User priority (178-256)
Reserved for processes started with rtprio () system calls.
U sed by system processes.
Assigned to user processes.
The kernel can alter the priority of time-share priorities (128-256) but not real- time priorities.
5-18 Process Management
Run Queues
A process must be on a queue of runnable processes before the scheduler can choose it to run. Figure 5-2 shows an abstraction of run queue organization.
Run queues are link-listed in decreasing priority. Each process is represented by its header on the list of run queue headers; each entry in the list of run queue headers points to the process table entry for its respective process.
Processes get linked into the run queue based on the process's priority, set in the process table.
Run Queue Headers
o
Real-Time
lime
12 12
System
Share 17
Priorities 17
User 7 8
7 8
X
l 256 1--1 - - - I LG200211_ 025
Proc table
--z....c==J ....
[ J [ J - - - . . XFigure 5-2. Run Queue, showing Priorities
Process Management 5-19
5
The kernel maintains separate queues for system-mode and user-mode execution. When a timeshare process is not running, the kernel improves the process's priority (lowers its number). When a process is running, its priority worsens. The kernel does not alter priorities on real-time processes.
Timeshared processes (both system and user) lose priority as they execute and regain priority when they do not execute.
The scheduler chooses the process with the highest priority to run for a given time-slice. system-mode priorities take precedence for CPU time. User-mode priorities can be preempted-stopped and swapped out to secondary storage;
kernel-mode priorities cannot. Processes run until they have to wait for a resource (such as data from a disk, for example), until the kernel preempts them when their run time exceeds a time-slice limit, until an interrupt occurs, or until they exit. The scheduler then chooses a new eligible highest-priority process to run; eventually, the original process will run again when it has the 5 highest priority of any runnable process.
5-20 Process Management
Process Context
When the kernel switches from executing one process to executing another process, it switches context. That is, the kernel switches from executing in the context of one process to the context of another process. When this happens, the kernel saves information about the interrupted process to be able to later resume execution. The kernel also restores the context of the process it is about to start.
system call \1\1\/11\1\/11\1\
system mode
! ~
Process 1 I
user mode I
lL
I
I I
I I
I I
I I
I
--- ~
Process 2 system mode
I
user mode
l
Time
--+-LG200211_ 026
Figure 5-3. System Switching Context from One Process to Another Context switching is shown in Figure 5-3. In this figure, the system switches from executing in the context of process P1 to executing in the context of process P2. The dotted vertical lines indicate the points of context switching.
Note that context switching can only take place when the process is executing in system mode.
Process Management 5-21
5
5
Process States and Transitions
Throughout the course of its lifetime, a process transits through several states.
Queues in main memory keep track of the process by its process ID. A process resides on a queue according to its state; process states are defined in the sys/proc.h include file. Events, such as receipt of a signal, cause the process to transit from one state to another.
Processes can be described as being in one of the following states:
idle run stopped sleep zombie
Process has either just been forked; an idle process can be scheduled to run.
Process is on a run queue, available to execute in either kernel or user mode.
Executing process is stopped by a signal or parent process.
Process is not executing, while on a sleep queue (for example, awaiting I/O to complete).
Having exited, the process no longer exists, but leaves behind for the parent process some record of its execution.
These states and their transitions are shown in Figure 5-4.
5-22 Process Management
fork()
acquiring system resources
shell sends a S I G C O N T
o
receivesSIGSTOP or is being traced
mode switch
swapper swaps
in process
process gets resource
waits for resource
process ends
process gets resource
swapper swaps
out process
Figure 5-4. Process States and Transitions
Process Management 5-23
5
5
When a program starts up a process, the kernel allocates a structure for it from the process table; the process is now in idle state, waiting for system resources. Once it acquires the resource, the process is linked onto a run queue and made runnable. When the process acquires a time-slice, it runs, switching as necessary between kernel mode and user mode. If a running process receives a SIGSTOP signal (as with control-Z in vi) or is being traced, it enters a stop state. On receiving a SIGCONT signal, the process returns to a run queue (in-core, runnable). If a running process must wait for a resource (such as a semaphore or completion of I/O), the process goes on a sleep queue (sleep state) until getting the resource, at which time the process wakes up and is put on a run queue (in-core, runnable). A sleeping process might also be swapped out, in which case, when it receives its resource (or wakeup signal) the process might be made runnable, but remain swapped out. The process is swapped in and is put on a run queue. Once a process ends, it exits into a zombie state.
Interrupts
Here is an example of how interrupts work:
Process A might make a system call requiring disk I/O. While waiting for the disk I/O to complete, Process A goes to sleep. Meanwhile Process B starts up.
The disk I/O completion generates an interrupt. In the course of completing the disk I/O, the driver controlling it also puts the sleeping Process A onto a run queue, making it runnable at a high priority, because Process A now holds a resource. Interrupt activity "belongs" to Process A, but happened while Process B was running. The interrupt is asynchronous to the thread of execution.
5·24 Process Management
Signals
Signals are transmissions between processes and are used for interprocess communication (IPe). Signals are also viewed as events to which processes respond.
An example of signal use is the kill command, which sends a SIGTERM signal to terminate the specifies processes.
When a process receives a signal, the process might ignore the signal,
terminate, defer the signal, or execute a signal handler. HP- UX defines several signal interfaces that allow a process to specify the action taken upon receipt of a signal. (See sigaction(2) signal(2), sigvector(2), bsdproc(2), and sigset(2V) in the HP- UX Reference Manual for the various HP- UX signal interfaces. See signal(5) for description of HP- UX signals. Acceptable signal values are defined in /usr/include/sys/signal.h.)
Process Management 5-25
5
Multiprocessing
Standard HP- UX executes in a uniprocessing system architecture consisting of one central processing unit (CPU), memory, and peripherals. The architecture of Series 870 and 890 systems supports multiprocessing (MP)-two, three, or four system processing units (SPUs), memory shared among the processors, and peripherals. Multiprocessing is a limited form of parallel processing.
Header files that define MP include mp. h, spinlock. h, and several
semaphore-related header files. MP header files can be read but they define operating-system behavior that is not configurable.
How Multiprocessing Compares to Uniprocessing
Despite architectural differences, multiprocessing systems execute code 5 identically to standard HP- UX. Although multiple processes can run
concurrently on the several processors, all processors use the same kernel code.
Symmetry
Symmetry in MP has to do with use of the SPU. With some asymmetrical MP systems, only a primary SPU can execute I/O and system code; other SPUs execute only user code. With symmetrical MP, every SPU can execute I/O and system code. One copy of the kernel resides in memory and controls all processors. Since any kernel task can execute on any processor in the MP system, HP -UX MP is termed symmetrical.
Multiprocessor Boot-Up
Boot-up procedure in an MP system is almost identical to that of a uniprocessing system. At boot-up, the processor-dependent code (PDC) arbitrates among the multiple processors to determine the "monarch processor." The serf (non-monarch, or remaining) processors wait in
"rendezvous code," while the monarch processor alone executes the bootup code. Upon reaching the MP portion of the configuration code (near the end of booting process), the monarch processor signals each serf processor in turn, to bring it into the multiprocessing environment, at which time they go into idle (see Figure 5-5, ready to run processes. Once all serfs are brought in, the monarch processor can go into idle also. From idle, processors do their work:
they look in run queues for processes that need CPU time, grab locks, execute 5-26 Process Management
processes, release locks, and thus perform their normal operations on behalf of the kernel.