COMSATS Institute of Information Technology

(Virtual Campus)

Discipline: BS (CS)
Course Code: CSC322
Name: Muhammad Usman
Registration #: SP15BSCS067
Date: 19-May-2018

Assignment No. 3
 Question No. 1
Why a computer need a Process? Write in detail how Linux manage a process.

Solution:
The way computers work is based on the lowest level details of how a CPU works. The CPU does
virtually everything, and the rest of the computer is just there to help it along. There is only a small
number of things a CPU needs in order to work: a clock to make it a machine (literally, a state
machine), memory to fetch code and data from and to write data to, & power, obviously. It can run
with just those ingredients. That doesn’t make it a computer, however. Most of these things, and
some other peripherals are generally aggregated on the motherboard of a computer.
All the CPU does is read code from memory, read data from memory, execute simple (very, very
simple) instructions, and write data to memory (and IO, which the CPU thinks is memory). That’s
really it. Nothing else. In order for the instructions it executes to make any sense, a programmer
creates programs that are lists of these instructions, and they include the logic of the program, as
well as the ability effect IO on peripheral devices, like the keyboard and mouse, video hardware,
disk drives, and a huge list of other stuff. The programs are just a linear list of the CPU instructions,
and can only be executed by the CPU when they are fetched, one-by-one, from memory. That leads
up to why we need storage.
Storage (completely distinct from memory) allows the programs to be, well, stored. So when the
lights go out, the program lives on to run another day. Memory loses all of it’s content when the
power goes off. Sadly, storage, by its physical nature, cannot be accessed instruction by instruction
in the linear organization that memory can. The CPU doesn’t have the concept of storage in its
makeup. In order for the digital information that makes up programs, operating systems,
bootloaders, and data files to be accessible to the CPU, they must be first transferred to memory.
The transfer of data to memory from storage, or the other way around, is done by using special
memory addresses (in that linear space that memory is composed of, and that the CPU has access
to). These are memory addresses that the computer designer assigned to access peripheral IO
hardware. The CPU reads from those addresses and writes to those addresses just as if they were
memory, which is all it can do. However, the computer designer arranges it so the storage devices
(actually, all devices) can transfer their contents to the computer memory when properly accessed
in this way. Once that transfer has taken place (normally done by an operating system, which is
just a special kind of program), then the CPU can access it and execute it. There are a lot of details
that go into that transfer, and there is special hardware that the CPU invokes to help it along and
optimize the process, but the end result is the same. You could call this process ‘dump to RAM’.
Programmers, sysadmins, and others call it a loader, and it generally is part of the Operating
System.
Managing a Process in Linux
we will walk through a basic understanding of processes and briefly look at how to manage
processes in Linux using certain commands.
A process refers to a program in execution; it’s a running instance of a program. It is made up of
the program instruction, data read from files, other programs or input from a system user.
Types of Processes
There are fundamentally two types of processes in Linux:
Foreground processes (also referred to as interactive processes) – these are initialized and
controlled through a terminal session. In other words, there has to be a user connected to the system
to start such processes; they haven’t started automatically as part of the system functions/services.
Background processes (also referred to as non-interactive/automatic processes) – are processes not
connected to a terminal; they don’t expect any user input.

How Does Linux Identify Processes?

Because Linux is a multi-user system, meaning different users can be running various programs
on the system, each running instance of a program must be identified uniquely by the kernel.
And a program is identified by its process ID (PID) as well as it’s parent processes ID (PPID),
therefore processes can further be categorized into:
• Parent processes – these are processes that create other processes during run-time.
• Child processes – these processes are created by other processes during run-time.
The Init Process
Init process is the mother (parent) of all processes on the system, it’s the first program that is
executed when the Linux system boots up; it manages all other processes on the system. It is started
by the kernel itself, so in principle it does not have a parent process.
The init process always has process ID of 1. It functions as an adoptive parent for all orphaned
processes.
You can use the pidof command to find the ID of a process:

# pidof systemd

# pidof top

# pidof httpd

Find Linux Process ID

To find the process ID and parent process ID of the current shell, run:

$ echo $$

$ echo $PPID

Find Linux Parent Process ID

Starting a Process in Linux
Once you run a command or program (for example cloudcmd – CloudCommander), it will start a
process in the system. You can start a foreground (interactive) process as follows, it will be
connected to the terminal and a user can send input it:

# cloudcmd

States of a Process in Linux

During execution, a process changes from one state to another depending on its
environment/circumstances. In Linux, a process has the following possible states:
Running – here it’s either running (it is the current process in the system) or it’s ready to run (it’s
waiting to be assigned to one of the CPUs).
Waiting – in this state, a process is waiting for an event to occur or for a system resource.
Additionally, the kernel also differentiates between two types of waiting processes; interruptible
waiting processes – can be interrupted by signals and uninterruptible waiting processes – are
waiting directly on hardware conditions and cannot be interrupted by any event/signal.
Stopped – in this state, a process has been stopped, usually by receiving a signal. For instance, a
process that is being debugged.
Zombie – here, a process is dead, it has been halted but it’s still has an entry in the process table.
How to View Active Processes in Linux
There are several Linux tools for viewing/listing running processes on the system, the two
traditional and well known are ps and top commands:
1. ps Command
It displays information about a selection of the active processes on the system as shown below:

# ps

# ps -e | head
List Linux Active Processes
 Question No. 2
Multilevel feedback queue scheduling algorithm is designed to favor IO bound
over CPU bound processes. How is this achieved? How does it make sure that
low priority, CPU bound background jobs do not suffer starvation?

Solution:
A variation on multilevel queues is to allow the scheduler to adjust the priority of a process during
execution: to relocate it from one queue to another based on the recent behavior of the process.
The goal of multilevel feedback queues is to automatically place processes into priority levels
based on their CPU burst behavior. I/O-intensive processes will end up on higher priority queues
and CPU-intensive processes will end up on low priority queues. The scheduler may choose from
a variety of algorithms to determine a priority level (e.g., the weighted average that we discussed).
One approach is to give high priority queues short time slices. The time slice increases for each
decreasing priority queue. A process initially starts in the highest priority queue.
Once it gets scheduled to run, it will either run and then block on some event or it will run until
the quantum expires. If the process blocks then the scheduler will move the process onto the same
priority queue when it is ready to run again. If, however, the process runs to expiration (i.e., the
scheduler sees that the process is still running when its quantum expires) then the scheduler
preempts the process and punishes it by placing it in the queue at the next lower priority level. As
long as a process uses the full quantum at each level, it continues to drop to lower priority levels
(eventually reaching the lowest level, where it circulates round robin).
At each lower priority level, the quantum is increased (so the process does not get the CPU often,
but gets to use more of it when it does get it). The rationale for this is that a processes at lower
levels have demonstrated that they are compute bound rather than I/O bound. By giving them a
fatter chunk of the CPU, but only when there are no higher priority processes to run, we can
minimize the context switch overhead and get more efficient use of the CPU. A process that waits
too long to be scheduled may be moved up to a high-priority queue (process aging). That will give
it a chance to run. If it does not use up its entire time slice, it will remain at that level. If it does
use up its time slice, it will drop the lower level and keep dropping as long as it continues to use
up its time slice. This mechanism is also a way to allow interactive processes to get rescheduled
back to a high priority even if they had to do some CPU-intensive work for a while. While it is
most common for each queue to circulate processes round-robin, as with multilevel queues, each
queue may have its own scheduling algorithm to determine the order in which the scheduler
removes a process from the queue. Multilevel Feedback Queue Multi-level feedback queues work
well in favoring I/O bound processes with frequent scheduling by keeping them at high priorities