Process Management

What we will cover

• Process management interface to the programmer
• Switching between kernel and use mode
• Why and How
• Context and stacks
• Process execution status/states
• Process Control Block
• Process scheduling methods
• Process priorities
 Examining a process
• e.g. $ file /home/iiitb/loopy

$ ./loopy busy $ ./loopy busy

Processes Multiple processes are simultaneously running

$ ps x - Not one after the other completes
… - They are unaffected by each other
5948 pts/1 R+ 0:06 ./loopy busy - Does not affect kernel operations
5949 pts/2 R+ 0:01 ./loopy busy
5950 pts/0 R+ 0:00 ps x
Process management APIs
• We’ve already seen fork(2) and exec(3) and wait(2)
(family of) calls
• Getting rid of a process: kill(1) kill(2)
• Try this from the command line
• See fork_and_termC.c
• Actually this system call, kill(2), does something more, we learn about it
later
• What processes exist on the system at any time (on linux)
• Use ps –ax, Or
• Examine /proc/ directory
Process priority
• All processes have a priority that determines how it will be scheduled
• Indicated by a ‘nice’ value in Linux
• A process that is nice to others has reduced scheduling chance…. So higher nice value,
lower the scheduling chance
• See ps –axl
• Some commands to manage priority:
• nice(1) nice(2) renice(1)
• Examples using nice and renice from the command line
• We can also change priority using system calls:
• getpriority(2), setpriority(2)
• See priority_ops.c
• More about this when we study scheduling
Kernel and user mode
Context Switching
Experiment: Forcing a program to spend
more time in User mode or kernel mode
• Any system call forces the process to run in kernel mode for the
period of the system call
• For example getpid(2)
• Run ./loopy kernel
• Also try ./loopy sleepy
• See top and observe the CPU time of the process
• You can also use the time command
A little experiment
• Try this: • Watch what happens with
• ./loopy sleepy strace or ltrace –S
• ./loopy busy • Watch what happens with top
• ./loopy kernel

Observation:
A busy loop with no calls (like an infinite loop) consumes a lot of CPU
A busy loop with indefinitely repeated system calls also consumes a lot of CPU
… but with a difference in the way the time is accounted
A loop with a sleep system call consumes negligible CPU
Mechanism:
Kernel and User mode CPU states
• Goal: Let user code run on CPU, but restrain what instructions user
can execute
• Mechanism 1: Hardware support for “mode” in the process status/ cpu flag.
• CPU in “user” mode is restricted in terms of instructions it can execute.
• Mechanism 2: Hardware support for “interrupts” to go between “user” and
”kernel” mode: Hardware support for:
• System call instructions from “user” mode execution (syscall on x86-64)
• See syscall.s and syscallC.c
• Exception handling
• See exceptions.c
• Hardware interrupts
• For IO, as a special case – Prearranged timer interrupts
 Why programs make system calls?
• The kernel has code that does a
Kernel 3---
Process virtual address space

-----
-----
lot of useful stuff like I/O
• System calls are the way these
2--- routines can be executed
libraries -----
----- • These activities need ‘privileged’
instructions which need careful
User
1---
-----
-----
execution.
• So there are two modes:
in Linux

• kernel mode – running kernel code

• User mode – running user code
 Switching between kernel and user mode
• User process often switch between “user” and “kernel” mode of
execution
CPU goes from executing use code to
Time executing kernel code every once in a while.
The reason to do this could be many –
• Timer interrupt
P1 • System call
• External interrupt
• Exception

P2

Kernel
Interrupts: Timer System call: IO request Interrupt: External
(WRITE(2)) device (IO complete) 12
About system calls (syscall in x86-64) 1. Se
2. Sa
3. Fin
• The system call is a 4. Ru
• Machine instruction (has an opcode) 1
• Is executed from the user mode code (usual user C code and libraries) D
• The instruction jumps the CPU to a predefined system call entry point in the kernel.
• This predefined entry point address is stored in a special register
• This register is initialized at boot time by kernel code.
• The instruction changes CPU mode from user mode to kernel mode
• Typically CPU bits are set
• Once the kernel finishes handling the request it executes a system call return
instruction.
• This resets the CPU mode bits
• On x86-64 these instructions are syscall and sysret (or sysenter/systexit), an
alternate is INT 0x80
How are multiple system calls handled
(Linux)
• There are a number of predefined system calls with a numeric code
for each. Eg. in Linux see :
• /usr/include/sys/syscall.h or
/usr/include/x86_64-linux-gnu/asm/unistd_64.h
• The user puts the required system call in a specific register and then
executes syscall instruction. (eg put 1 into rax for WRITE system call)
• The system call handler will use a system call table to jump
to the appropriate handler 0 sys_read
System 1 sys_write Address of the
call sys_open corresponding
numeric 2 handler in the
sys_close kernel
codes 3
sys_stat
4
More about the system call(syscall in x86-64)
1. Syscall instruction
1. Change mode to kernel mode
2. Saves some process state
3. Starts executing the system call handler entry_syscall_64
2. entry_syscall_64
1. Stack switches to kernel stack
2. Saves rest of process state
3. Looks up the syscall table and executes the specific handler code
4. On return from the syscall handler restore any state information
5. Execute sysret which reverses the mode and some flags and goes back
to user code execution.
 A simplified syscall
handling
mechanism CPU
---P1---
---------
--------- 1
Syscall table ST
---P3--- Syscall entry_syscall_64
--------- ---------
-------- --------- HW support for save
--------- mode change call refers ST 1
--------- Running process restore
sysret ----
---P2--- ---P4---
--------- --------- System call 1 handler
-------- -------- ----
--------- --------- return
--------- ---------
 Ref: www.ostep.org (Ch 6 Fig 6.2)
Context Switching
Kernel code Hardware support User code
• Process in user mode
executes a syscall

• Context is stored in kernel

stack, set to ‘kernel’ mode, CTX
jump to address in kernel

• Do the syscall, and then do

SYSRET
• Restore context, set mode CTX
to ‘user’, jump to the user
code
• Continue executing user
code
Process information and process context of a
running process
• A process has some attributes – stored as part of the PCB structure:
PCB
• Process id, parent process information
• List of open files
• Info on memory occupied
• Register values, including PC, flags etc. - called Context of a process
• Scheduling information – time used and scheduling parameters (priority etc)
• - PCB = “Process Control Block”
• Context is stored in the PCB when task is not running, eg when switching
from one task to another.
• Context helps to restore a process when it has to rerun.
CTX
• Process table stores a mapping pid  PCB
Process states
Process states
• At any time many processes are “executing” on the system. See
ps –ax for instance.
• All the PCBs exist in the kernel.
• Only one of them is for a process running on the CPU (assume single
CPU). That process is said to be in ‘RUNNING’ state.
• Most processes are waiting for something to happen.
• Explore ps -ax -o pid,comm,stat,wchan
• See the stat and wchan columns
• For processes waiting on something the wchan column says where in the
kernel the wait is happening
 Process states and transitions
Running
(U)
SYSCALL
R R
SYSRET
CPU Scheduler
Ready Running

Process terminated,
R Running or runnable Unblocking eg by exit()
Blocking Request
event
S Sleeping

Z Zombie Terminal
Z
Blocked S
Indicate as seen on
Linux ps command output
(just a sample!)
Terminated state and zombie processes
• It is not unusual that the child process terminates before the parent
• When the child terminates, the parent is expected to issue a wait()
system call to get the child information.
• Therefore in Linux the child enters the terminated state. In this state it
is no longer schedulable. It simply waits for its parent to read its exit
status. Once parent has read the exit status, the child PCB is removed.
• This state is also called zombie state
• See fork_and_termC.c
Orphaned processes
• It is possible for the parent to exit early and the child to continue to
run.
• Such processes are called ‘orphaned processes’ – i.e., it is alive, but its
parent has terminated.
• How they are dealt with:
• On some OSes this causes all children to terminate too.
• On Linux the process is allowed to run; however, its parent is changed
• This is called reparenting the process.
• A specific process such as systemd is assigned as the new parent process.
• Example: See fork_and_termP.c
Exploring process states in Linux
• Use ps -ax -o pid,comm,stat,wchan
• Run loopy , use ^Z and fg to toggle states
• See fork_and_termC.c, fork_and_termP.c and
zomB.c
What have we learnt ?
• Processes can be managed (created, destroyed) using system calls
• Process details can be discovered using ps on Linux
• Processes have a priority that can be changed
• CPU has two modes (user and kernel) mode,
• System calls, exceptions and hardware interrupts takes us between these
modes - context switch
• We understand how a system call works
• We know that a process can be in one of these states: Ready, Running,
Blocked, Terminated.
• We saw some programming experiments to understand these concepts.