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 management APIs (more)
• ^Z, bg, fg, jobs, ^C
• All jobs under one (virtual) terminal (like pts/2) are in one session
• A job is a fancy word for the process (or processes) on a single
command
• ls –l
• ps
• objdump –d ./a.out | grep syscall Note how this commands has two processes running
 Linux: Processes, Process Groups, session, session
leader, tty, foreground process-group etc.
$ ./loopy busy &
$ ./loopy busy &
$ sort | more Notice all these are running, not yet done.
….
On another terminal lets do a ps and know more about these 4 processes

PID PPID COMM TT STAT UID GID PGID SID

1312 2485 bash pts/4 Ss 1000 1000 1312 1312
2007 1312 loopy pts/4 R 1000 1000 2007 1312
2009 1312 loopy pts/4 R 1000 1000 2009 1312
2088 1312 sort pts/4 S+ 1000 1000 2088 1312
2089 1312 more pts/4 S+ 1000 1000 2088 1312
Note: For more details on how this is used for terminating processes and so forth, see this
interesting write up: https://linusakesson.net/programming/tty/index.php
Process priority – in Linux all regular
processes have a ‘nice value’
• 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) Try this on a terminal
$ ./loopy busy
• See priority_ops.c
$ renice -n 10 <pid of above process>
• More about this when we study scheduling $ nice –n 5 ./loopy busy
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
System call: IO request Interrupt: External Exception (div by zero)
Interrupts: Timer
(WRITE(2)) device (IO complete) 14
About system calls (syscall in x86-
64) See code to make
direct syscalls:
• The system call is a syscallC.c and syscall.s
• Machine instruction (has an opcode)
• Is executed from the user mode code (usual user C code and libraries)
• 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, in x86-64 this is in the CS register
• 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 (older) 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.
Aside: Browse Linux kernel source
• Go to: https://kernel.org/
• There you can download the source for the kernel version you are
interested in (perhaps the version you are running)
• Alternately, just browse the code, if you know what file you are looking for.
• As an example entry_syscall_64 is in arch/x86/entry/entry_64.S
• You can also use the elixir online cross reference tool for linux source to
search for symbols: https://elixir.bootlin.com/linux/v5.15/source (replace
v5.15 by any kernel version - with the ‘v’) and search for entry_SYSCALL_64
• See also
https://0xax.gitbooks.io/linux-insides/content/SysCall/linux-syscall-1.html
Understanding HW-SW interface
• When kernel boots up it store in a special register:
• wrmsrl(MSR_LSTAR, entry_SYSCALL_64);
• Syscall instruction jumps to that address
 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(user mode)
• Process in user mode
executes a syscall

• Context is stored in kernel

stack, set to ‘kernel’ mode,
jump to address in kernel
syscall handler

• Do the syscall, and then do

SYSRET
• Restore context, set mode
to ‘user’, jump to the user
code
• Continue executing user
code
 Ref: www.ostep.org (Ch 6 Fig 6.3)
Context Switching
Kernel code - scheduling Hardware support User code (user mode)
• Process A in user mode
doing some computation

• Timer interrupt – Kernel

mode - Save A’s context
(PC,regs,…), execute kernel
handler

CTX
• Do the elaborate context
and find the right process to
switch() to… say B

• Restore B’s context – go to

user mode - jump to the
user code
• Process B continues from it
left off
Recall PCB: 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 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.