assignment 4

MSRSAS - Postgraduate Engineering and Management Programme - PEMP

Advance System Programming i

EMBEDDED PROCESSORS AND MICRO CONTROLLERS

Module Code ESD 528

Module Name Advance System Programming

Course M.Sc in Real-Time Embedded Systems

Department Computer Engineering

Name of the Student Bhargav Shah

Reg. No CHB0911001

Batch Full-Time 2011

Module Leader Jishmi jos c

PO

STG

RA

DU

ATE

EN

GIN

EER

ING

AN

D M

AN

AG

EM

EN

T P

RO

GR

AM

ME –

(P

EM

P)

M.S.Ramaiah School of Advanced Studies Postgraduate Engineering and Management Programmes(PEMP)

#470-P Peenya Industrial Area, 4th Phase, Peenya, Bengaluru-560 058

Tel; 080 4906 5555, website: www.msrsas.org

ii

Declaration Sheet Student Name Bhargav Shah

Reg. No CHB0911001

Course Real Time Embedded System Batch Full-Time 2011

Batch FT-11

Module Code ESD528

Module Title Advance System Programming

Module Date 19/3/2012 to 14/4/2012

Module Leader Jishmi jos c

Extension requests: Extensions can only be granted by the Head of the Department in consultation with the module leader.

Extensions granted by any other person will not be accepted and hence the assignment will incur a penalty.

Extensions MUST be requested by using the „Extension Request Form‟, which is available with the ARO.

A copy of the extension approval must be attached to the assignment submitted.

Penalty for late submission Unless you have submitted proof of mitigating circumstances or have been granted an extension, the

penalties for a late submission of an assignment shall be as follows:

Up to one week late: Penalty of 5 marks

One-Two weeks late: Penalty of 10 marks

More than Two weeks late: Fail - 0% recorded (F)

All late assignments: must be submitted to Academic Records Office (ARO). It is your responsibility to

ensure that the receipt of a late assignment is recorded in the ARO. If an extension was agreed, the

authorization should be submitted to ARO during the submission of assignment.

To ensure assignment reports are written concisely, the length should be restricted to a limit

indicated in the assignment problem statement. Assignment reports greater than this length may

incur a penalty of one grade (5 marks). Each delegate is required to retain a copy of the

assignment report.

Declaration The assignment submitted herewith is a result of my own investigations and that I have conformed to the

guidelines against plagiarism as laid out in the PEMP Student Handbook. All sections of the text and

results, which have been obtained from other sources, are fully referenced. I understand that cheating and

plagiarism constitute a breach of University regulations and will be dealt with accordingly.

Signature of the student Bhargav Shah Date 14/4/2012

Submission date stamp (by ARO)

Signature of the Module Leader and date Signature of Head of the Department and date


Advance System Programming iii

Abstract ____________________________________________________________________________

The kernel is the central part of an operating system that directly controls the computer

hardware. Linux kernel is a very complex and monolithic software system. It is one of the most

prominent examples of free and open source software.

In the chapter 1, a debut is done on performance of modern File System, ext4, and

comparison of its characteristics and performances with its predecessors, ext3 and ext2 File

Systems. Future plans for the improvement of ext File System is explained in details.

In any operating system the kernel information is privileged information. To access the

kernel information from the user process we need to use the system call. In chapter 2 a new

system call is added, system calls provide the interface between a process and the operating

system. A system call executes in the kernel mode. Every system call has a number associated

with it. This number is passed to the kernel and that's how the kernel knows which system call

was made. When a user program issues a system call, it is actually calling a library routine. The

kernel executes the system call and returns the result to the user program using a register.

In the chapter 3, This part of the assignment involves evaluating the context switching

using the developed system calls. System calls which are developed in the chapter 2 to collect

information about the context switches for different number of tasks and under different

priorities. Then it is tested using different kinds of loads to know its efficiency and suggestions

are given for further improvement.

iv

Contents ____________________________________________________________________________

Declaration Sheet ......................................................................................................................... ii Abstract ....................................................................................................................................... iii Contents ........................................................................................................................................iv

List of Tables ................................................................................................................................. v List of Figures ..............................................................................................................................vi List of Symbols .......................................................................................................................... vii PART-A ......................................................................................................................................... 8 CHAPTER 1: ext4 File System Performance Analysis in Linux .................................................. 8

1.1 Introduction to Linux File System ....................................................................................... 8 1.2 Characteristics of ext4 File System[1] ................................................................................ 8

1.3 Critical comparative analysis of ext3 and ext4 [2] .............................................................. 9 1.4 Performance of ext3 and ext4 for small, medium, large and ultra large file sizes [3] ........ 9 1.5 Future direction for evolution of the ext File System[4] ................................................... 10 1.6 Conclusion ......................................................................................................................... 11

PART-B ....................................................................................................................................... 12

CHAPTER 2: Implementation of System call ............................................................................ 12 2.1 Introduction ....................................................................................................................... 12

2.2 Design & Flow Chart ........................................................................................................ 12 2.3 Implementing system call (sys_getnvcsw and sys_getnivcsw) ......................................... 15

2.4 Compiling and booting the modified kernel ...................................................................... 18 2.5 Developing and testing suitable test cases ........................................................................ 19 2.6 Verification of the system call results ............................................................................... 20

2.7 Conclusion ......................................................................................................................... 20

PART-C ....................................................................................................................................... 21 CHAPTER 3: Context switch associated different scenario of process ...................................... 21

3.1 Introduction ....................................................................................................................... 21

3.2 Design of user space scenarios .......................................................................................... 21 3.3 Implementation of the scenarios & Results ....................................................................... 23

3.4 Tabulation of obtained results ........................................................................................... 30 3.5 Analysis of obtained result ................................................................................................ 31 3.6 Suggestion for improvement of context switch mechanism in Linux ............................... 32

3.7 Conclusion ......................................................................................................................... 33 CHAPTER 4 ................................................................................................................................ 34

4.1 Module Learning Outcomes .............................................................................................. 34 References ................................................................................................................................... 35

Appendix ..................................................................................................................................... 36


Advance System Programming v

List of Tables ____________________________________________________________________________

Table 1.1 Comparison of ext3 and ext4 ........................................................................................ 9

Table 3.1 Obtained results……………………………………………………………………31

vi

List of Figures ____________________________________________________________________________

Snippet 2. 1 Variables of rusage structure ................................................................................... 12 Snippet 2. 2 Instance of rusage structure ..................................................................................... 13 Snippet 2. 3 Calling of the getrusage() ........................................................................................ 13 Snippet 2. 4 Assigning the pointer to the structure ..................................................................... 13

Snippet 2. 5 Calling of the system call from user process .......................................................... 13 Snippet 2. 6 Body of system call ................................................................................................. 14 Snippet 2. 7 Appending syscall_table.h ...................................................................................... 15 Snippet 2. 8 Appending unistd_32.h ........................................................................................... 15 Snippet 2. 9 Appending unistd_64.h ........................................................................................... 16

Snippet 2. 10 Appending syscalls.h ............................................................................................. 16 Snippet 2. 11 Syscall body .......................................................................................................... 16

Snippet 2. 12 Appending makefile .............................................................................................. 17 Snippet 2. 13 User application .................................................................................................... 17 Snippet 2. 14 Testing algorithm .................................................................................................. 19 Snippet 2. 15 Testing results ....................................................................................................... 19 Snippet 2. 16 Verification of values ............................................................................................ 20

Snippet 3. 1 CPU bound with same priority ................................................................................ 23

Snippet 3. 2 Execution of two CPU bound processes ................................................................. 23 Snippet 3. 3 IO bound with default priority ................................................................................ 24

Snippet 3. 4 Execution of two IO bound process ........................................................................ 24 Snippet 3. 5 One IO bound one CPU bound with default priority .............................................. 25 Snippet 3. 6 Execution of One IO bound one CPU bound with default priority ......................... 25

Snippet 3. 7 CPU bound with different priority .......................................................................... 26

Snippet 3. 8 Execution of two CPU bound process with different priority ................................. 27 Snippet 3. 9 Two IO bound with different priority ..................................................................... 27 Snippet 3. 10 : One CPU bound and one I/O bound process with different priority .................. 28

Snippet 3. 11 Execution of Two IO bound process with different priority ................................. 28 Snippet 3. 12 Execution of One CPU bound and one I/O bound process with different priority

..................................................................................................................................................... 29 Snippet 3. 13 One CPU bound and one I/O bound process with lower priority for CPU bound

process ......................................................................................................................................... 29

Snippet 3. 14 Execution of 13 One CPU bound and one I/O bound process with lower priority

for CPU bound process ................................................................................................................ 30

Snippet 3. 15 Schedule logic of Linux ........................................................................................ 32


Advance System Programming vii

List of Symbols ____________________________________________________________________________

Fsck File System ChecK

I/O Input and output

PART-A

CHAPTER 1: ext4 File System Performance Analysis in Linux

1.1 Introduction to Linux File System

File systems organize the data stored on computer hard drives, keeping track of the physical

locations of all data elements on disk while allowing users to quickly and reliably retrieve files

when needed.Ext4 is the evolution of the most used Linux file system, Ext3. In many ways, Ext4 is

a deeper improvement over Ext3 than Ext3 was over Ext2. Ext3 was mostly about adding

journaling to Ext2, but Ext4 modifies important data structures of the file system such as the ones

destined to store the file data. The result is a file system with an improved design, better

performance, reliability and features.

1.2 Characteristics of ext4 File System[1]

Compatibility: Any existing Ext3 file system can be migrated to Ext4 with an easy procedure

which consists in running a couple of commands in read-only mode. It can improve the

performance, storage limits and features of current file systems without reformatting and/or

reinstalling OS and software environment.

Extents: An extent is basically a bunch of contiguous physical blocks. It says "The data is in the

next n blocks". Extents improve the performance and also help to reduce the fragmentation, since

an extent encourages continuous layouts on the disk.

Multiblock allocation: Ext4 uses a "multiblock allocator" (mballoc) which allocates many blocks

in a single call, instead of a single block per call, avoiding a lot of overhead. This improves the

performance, and it's particularly useful with delayed allocation and extents. This feature doesn't

affect the disk format.

Fast fsck: Fsck is a very slow operation, especially the first step: checking all the inodes in the file

system. In Ext4, at the end of each group's inode table will be stored a list of unused inodes (with a

checksum, for safety), so fsck will not check those inodes. The result is that total fsck time

improves from 2 to 20 times, depending on the number of used inodes.

File Sizes:Ext4 adds 48-bit block addressing, so it will have 1 EB of maximum filesystem size and

16 TB of maximum file size.

Journal checksumming: ext4 uses checksums in the journal to improve reliability, since the

journal is one of the most used files of the disk. This feature has a side benefit: it can safely avoid a

disk I/O wait during journaling, improving performance slightly


Advance System Programming 9

1.3 Critical comparative analysis of ext3 and ext4 [2]

Table 1.1 Comparison of ext3 and ext4

Behavior Ext3 Ext4

Available Starting from Linux Kernel 2.4.15 Starting from Linux Kernel 2.4.19

Size 16 TB of maximum filesystem size,

and 2 TB of maximum file size

1 EB of maximum filesystem size

and 16 TB of maximum file size

Sub directory

Scalability

maximum 32000 maximum of 64,000 subdirectory

Extents

Indirect block mapping scheme to

keep track of each block used for the

blocks corresponding to the data of a

file

It basically says "The data is in the

next n blocks"

Block Allocation

Ext3 block allocator only allocates one

block (4KB) at a time

Ext4 uses a "multiblock allocator"

which allocates many blocks in a

single call

1.4 Performance of ext3 and ext4 for small, medium, large and ultra large file

sizes [3]

File systems are tested by Postmark Benchmark software. It simulates the Internet Mail

server load. The file operations are performed randomly in order to provide the credibility of the

simulation. Number of files, their size range and number of transactions are fully configurable. the

results of three different test cases are

Small files: Small files, ranging from 1bytes to 1K. Used Postmark configuration was, file size

range from 1 to 1000, number of generated files was 30000 and number of performed transactions

was 50000. Performance results for each file operation are given on the Figures 1.4.1a and 1.4.1b

(see appendix A).In this test ext4 file system is more than 10% faster than ext3, while it is more

than 70% faster than ext2. At the same time, ext3 file system is more than 60% faster than ext2.

Medium files: Medium files, rang from 1K to 100K, appropriate Postmark configuration used for

this test was, file size range from 1000 to 100000, number of generated files was 4000, and number

of performed transactions was 50000. Performance results for each file operation are given on the

Figures 1.4.2a and 1.4.2b(see appendix A). In this test ext4 file system has shown superior



performances comparing to the performances of its predecessors. Ext4 is more than 40% faster than

ext3, and almost twice as fast as ext2.

Large files: This is also a very intensive test procedure as it involves a large number of very small

files, ranging from 1bytes to 1K. Used Postmark configuration was: file size range from 1 to 1000,

number of generated files was 30000 and number of performed transactions was 50000.

Performance results for each file operation are given on the Figures 1.4.3a and 1.4.3a (see appendix

A).In this test ext4 file system is more than 46% faster than ext3, while about 73% faster than ext2.

At the same time, ext3 file system is over 18% faster than ext2.

1.5 Future direction for evolution of the ext File System[4]

Evolution is generally defined as "a series of changes over a period of time, resulting in

something new arising".

Ext4, is latest filesystem. This new filesystem incorporates scalability and performance

enhancements for supporting large filesystems, while maintaining reliability and stability. Ext4 will

be suitable for a larger variety of workloads and is expected to replace ext3 as the “Linux

filesystem.”

Large filesystem: Evolution of the ext File System greatly depends on the file size ,the file sizes

for the different files are as follows, ext-64MB, ext2- 4TB, ext3-16 TB, ext4-1 EB 48-bit block

numbers here block size is limited in ext-4,the solution to this problem is to use the metablock

group feature (META_BG) incorporation as a future work.

Extent: An extent is a single descriptor which represents a range of contiguous physical blocks.

Which are introduced in ext3 and continued in ext4. Extents are not very efficient for representing

sparse or highly fragmented files. So in future, for highly fragmented files, we could introduce a

new type of extent, a block-mapped extent. A different magic number, stored in the extent header,

distinguishes the new type of leaf block, which contains a list of allocated block numbers

Inodes: The maximum number of inodes has to be fixed at filesystem creation time. To avoid

running out of inodes later, users often choose a very large number of inodes up-front. The

consequence is unnecessary disk space has to be allocated to store unused inode structures. The

wasted space becomes more of an issue in ext4 with the larger default inode.so in future inodes

should design such that unnecessary disk space has to be allocated to store unused inode structures.

Uncompressed data: The basic idea is to do the compression in userspace, using libz with regular

resync points every 64k or 128k of uncompressed data. An array, indexed by each fixed-block of

uncompressed data, is located at the beginning of the file indicating where each compressed block

begins. The file is stored on-disk written by the installer in a compressed format, and then the



installer flips an attribute bit which marks the file as containing compressed data, and which also

makes the file immutable. (Any attempt to open the file read/write will result in an error.)

The advantage of this scheme is that it minimizes in-kernel complexity, since the kernel doesn't

have to deal with compressing data, and it means of using a simpler format which is more efficient

from a compression standpoint since we don't have to deal with random access writ

1.6 Conclusion

In this part of assignment a debut is done on performance of modern File System, ext4, and

comparison of its characteristics and performances with its predecessors, ext3 and ext2 File

Systems. Future plans for the improvement of ext File System is explained in details.

A File System is a way to organize data expected to be retained, after a program terminates.

It is done by providing procedures to store, retrieve and update data, as well as manage the

available space on the devices which contain it. ext4 File System is the successor of the ext3 and

ext2 File System.

It is supported on today‟s most popular Linux distributions. In contrast to the 32-bit ext3

File System, that has only some features added to its predecessor ext2 and maintains a data

structure as in the ext2 File System. ext4 File System includes many improvements, especially

when comparing to ext3 File System, but being the 64-bit File System, ext4 is much cumbersome.



PART-B

CHAPTER 2: Implementation of System call

2.1 Introduction

A kernel is the operating system software running in protected mode and having access to

the hardware's privileged registers. The kernel is not a separate process running on the system it

runs along with all processes. Multitasking refers to an operating system in which multiple

processes, can execute (run) on a single computer seemingly simultaneously and without interfering

with each other. That is, each process has the illusion that it is the only process on the computer and

that it has exclusive access to all the services of the operating system.

Basically, multitasking is accomplished by kernel, which switches control between

processes rapidly, using the clock interrupt (and other means) to trigger a switch from one process

to another. This phenomenon is known as the context switching. Linux kernel keeps track of the

number of context switches happens in a life spam of process.

A system call is how a program requests a service from an operating system's kernel. This

may include hardware related, creating and executing new processes, and communicating with

integral kernel services (like scheduling).As a part b if this assignment two system call is created

named sys_getnvcsw and sys_setnivcsw to send number of voluntary and involuntary context

switch for calling process in user space.

2.2 Design & Flow Chart

The function getrusage and the data type struct rusage are used to examine the resource

usage of a process. They are declared in „sys/resource.h‟.The getrusage function retrieves process

Snippet 2. 1 Variables of rusage structure



data from the kernel. It can be used to obtain statistics either for the current process by passing

RUSAGE_SELF as the first argument, or for all terminated child processes that were forked by this

process and its children by passing RUSAGE_CHILDREN. The second argument to rusage is a

pointer to a struct rusage variable, which is filled with the statistics. Snippet 2.1 shows the data type

stores various resource usage statistics. In the context of assignment question, for getting the

number of the context switches (voluntary and involuntary) which stored in ru_nvcsw and

ru_nicvsw integer variables of rusage structure one instance of the structure has to be

created.Snippet 2.2 shows the two instance of rusage, named bhargav and structure pointer p is

created.

Snippet 2. 2 Instance of rusage structure

Now, as per the design of the getrusage () it will take two argument.The first argument is the

macro through which kernel can identify that user need information about parent or child.In this

case only parent process (main() process) comes in picture as there is no requirement of forking.

As the second argument the function takes the address of the empty structure which has the same

size of rusage structure (which is created in above step).Snippet 2.3 shows the calling of the

getrusage() function with appropriate arguments.

Snippet 2. 3 Calling of the getrusage()

As the result of above calling process, whole resource usage structure for the calling process

is stored in bhargav structure. By using the dot(.) operator any variable can be access. Snippet 2.4

shows the mechanism for assigning the address of the structure to the structure pointer *p.

Snippet 2. 4 Assigning the pointer to the structure

In this step , address of the structure pointer and the size of the structure pointer infect that is

the size of the actual structure itself is passed to the created system call. Snippet 2.5 shows this

mechanism.

Snippet 2. 5 Calling of the system call from user process

At above statement processer will be interrupted from the current running process and in the

interrupt context this system call will be served. System call body, which is written in the kernel

space will take this arguments as one source pointer named *src and length of the source to be



copied in the kernel from user space. With the help of the copy_from_user(), whole usage structure

for the process(which is running in the user space) is being copied to the address of one structure

instance „y‟ which is same in size of rusage. After storing the structure in to the kernel space by

using the dot(.) operator any of the value can be addressed.

Snippet 2. 6 Body of system call

Snippet 2.6 shows the body of the system call. Which returns number of the voluntary

context switches for the current running process in user space.

Note: Above explained design is for returning the number of voluntary context switches to the user

space. In the case of the involuntary switches, same mechanism is used. Only the instance of the

rusage is taken as „y1‟ and the return value is changed.

General flow graph for system call

Figure 2. 1 General flow graph of system call

Figure 2.1 shows the general flow graph of the system call. User application lies in user

space and system call body is in kernel space. In the user application the kernel privilege data can

Calling of the system

call from user space

with appropriate

arguments.

System calls

service routine

written in

kernel space to

serve system

call.



accessed by the system call. System call body will start a new kernel thread to serve the user

application.

2.3 Implementing system call (sys_getnvcsw and sys_getnivcsw)

The procedure to create a system call varies in different versions of Linux [5]. Here

provided procedure is for the Debian with kernel 2.6.36.1.In this process of adding the system call,

recompilation of the kernel is essential so, Linux source tree must be installed on system. There is a

way to add system calls without recompiling the kernel using modules as a wrapper, but that is

beyond the scope of this document. Generally there is a five step procedure for developing the

system call which is describe below.

1. Modify the architecture specific sources to point to syscall code

We simply need to add the name to the syscall table and a reference to the index needs to be

placed in unistd.n Register the system call symbolic name with the kernel by appending the line:

.long sys_getnicvsw and .long sys_getncvsw at the end of $linux/arch/x86/kernel/yscall_ table_ 32

.S. Snippet 2.7 shows this modification.

Snippet 2. 7 Appending syscall_table.h

Snippet 2. 8 Appending unistd_32.h

Register the system call number with the kernel by appending the line #define

__NR_sys_getncvsw 341 and __NR_sys_getnicvsw 342 after the line #define __NR_prlimit64

340 in the file $linux/arch/x86/include/asm/unistd_32.h. This file is included by userspace

programs to reference the system call for 32 bit architecture.Snippet 2.8 shows this

modification.

Register the system call number with the kernel by appending the line #define __NR_getncvsw

303,__SYSCALL(__NR_getnvcsw,sys_getnvcsw) for sys_getnvcsw system call and #define

__NR_getnicvsw 304,__SYSCALL(__NR_getnivcsw,sys_getnivcsw) for sys_getnicsw system

call after the line (__NR_prlimit64,sys_prlimit64) in the file $linux /arch /x86 /include /asm/



unistd _64.h. This file is included by user space programs to reference the system call for 64 bit

architecture. Snippet 2.9 shows this modification.

Snippet 2. 9 Appending unistd_64.h

2. Modify the generic source files to point to syscall code

Add a function prototype of system call in syscalls.h. Add the system call to the

$linux/include/linux/syscalls.h file by adding the line asmlinkage long sys_getncvsw (unsigned

long *src,int len) and asmlinkage long sys_getnicvsw (unsigned long *src1,int len1) to the system

call list just before #endif line.This modification is hown by the Snippet 2.10.

Snippet 2. 10 Appending syscalls.h

3. Create the code system call (system call body)

This function is the one which should run on the occurrence on the particular system call.

System call body is placed in the ipc folder in the source tree named as bhargav1.c for voluntary

context switch number and bhargav2.c for involuntary context switch. Snippet 2.11 shows such

addition of files.

Snippet 2. 11 Syscall body



4. Update Makefile

Here system call is placed in the ipc folder of source tree. So,addition in the make file of the

ipc folder is essential to generate executable (.o) file. Strings obj-y += bhargav1.o and obj-y +=

bhargav2.o is written at the end of the make fine. Snippet 2.12 shows the edition of the make file

for compiling system calls with kernel compilation.

Snippet 2. 12 Appending makefile

5. Creating a user application to take the service from designed the system call

Compile, install, and boot to the modified kernel. For simple testing of the system one

application program (Driver program) is essential. As the initial part of the testing One user

application is created which will print 10000 times HI on screen. After this process system call

which are designed above is called. Snippet 2.13 shows the Created user application.

Snippet 2. 13 User application



2.4 Compiling and booting the modified kernel

After configuring the systemcall perfectly kernel compilation is done to use system call

from user domain. Linux kernel can be compiled natively in the Linux environment using the native

“gcc” compiler. Make files allow configuration changes using particular make options. The steps

involved in compiling the kernel are:

1. Call the make utility within the un-tarred Linux kernel code (in this case Linux-2.6.36.1)

directory with the required option – menuconfig, defconfig, xconfig and so on. menuconfig

is used to edit the text based version of linux. xconfig is used to edit the windows and other

GUI tools in KDE system and gconfig is used to edit same but in gnome system. Before this

the directories can be cleaned using the make mrproper and make clean options. The 'make

clean' purges any now-unwanted files left from previous builds of the kernel. The „make

clean' purges any now-unwanted files left from previous builds of the kernel.

2. Once the compilation configuration is done use the make command to compile the kernel.

The make utility is embedded in UNIX/Linux. To compile project, first need to compile

each source file into an object file, this in turn needs to be linked with system libraries into

the final executable file.

3. Once the kernel compiles successfully use the make modules and then the make

modules_install options to compile and install modules into the kernel. Loadable modules

are compiled and installed in the /lib/modules directory.

4. Then use the make install option to install the kernel in the /boot partition. Generally there

will be a file named INSTALL that contains installation instructions for any

application/kernel.

5. Then switch to the /boot partition and use the mkinitramfs with the –o option to create the

RAM disk file as shown mkinitramfs –o initrd.img-<ver>.

6. GRUB (GRand Unified Bootloader) is a boot loader package developed to support multiple

operating systems/kernel and allow the user to select among them during boot-up. After

installing the modules and kernel it is essential to update the grub file to see the installed

kernel version in the boot option. So, use update-grub to update the boot entries in the grub

file.



2.5 Developing and testing suitable test cases

A simple application program is created to test the system call, which is defined in installed

kernel. From user domain application programme will create one process to write A to Z on the

screen. After completion of task, programme makes system call with appropriate parameters. As the

return value of this system call is the number of the voluntary and involuntary context swatches.

Snippet 2.14 shows the testing algorithm which is created. The Results of the testing algorithm is

sown is the snippet 2.15.

Snippet 2. 14 Testing algorithm

Snippet 2. 15 Testing results

Creating a member of

rusage structure and a

pointer to structure

Calling getrusage

with source and

destination structure

address

Calling of system call with pointer

to structure and size of same

A pseudo process

which is created by

above block of code

Return value of system

call(Number of context

switches of pseudo process)



2.6 Verification of the system call results

As the part of the verification of the system call , testing algorithm is modified . For

verification, the testing algorithm will prints the number of the context switches from the local

rusage structure and value return from the context switch. The number of context switch should

come same. This result is documented as snippet 2.16.Number of context switches is same form

local structure and the system call.

Snippet 2. 16 Verification of values

2.7 Conclusion

Two system call named sys_getnvcsw and sys_getnicvsw has been designed and tested. It

gives the number of voluntary and involuntary context switches for the current running process.

Designed system call can be used on the system process to check the number of context switches.

Using structure rusage two system calls are implemented in this chapter which gives the number of

context switches for seven cases discussed in next chapter. Designed system calls are tested with a

random user program

Number context

switches retrieved from

local structure rusage

Number of context

switches retrieved

from system call



PART-C

CHAPTER 3: Context switch associated different scenario of process

3.1 Introduction

"The Process is one of the fundamental abstractions in Unix/Linux Operating Systems, the other

fundamental abstraction being files."[6]

A program is an executable file that is held in storage. Storage refers to devices or media

that can retain data for relatively long periods of time (e.g., years or even decades), such as hard

disk drives (HDDs), optical disks and magnetic tape. This contrasts with memory, whose contents

can be accessed (i.e., read and written to) at extremely high speeds but which are retained only

temporarily (i.e., while in use or only as long as the power supply remains on).

An executable file is a binary file that has been compiled (i.e., converted using a special

type of program called a compiler) from source code into machine code, which is a pattern of bytes

that can be read directly by a central processing unit (CPU). Source code is the version of software

as it is originally written by a human in plain text . A CPU is the main logic unit of a computer.

A program is a passive entity until it is launched, and a process can be thought of as a

program in action. Processes are dynamic entities in that they are constantly changing as their

machine code instructions are executed by the CPU. Each process consists of (1) system resources

that are allocated to it, (2) a section of memory, (3) security attributes (such as its owner and its set

of permissions) and (4) the processor state.

Process can be classifies in either IO bound or CPU bound. The process which spends more

time in waiting for IO operation is known as the IO bound process. On the other side of coin, the

process which spends more time in performing arithmetic operation without waiting for IO is

known as CPU bound process.

Priority, the idea is to rank process based on their worth and need of the processor time. The

process with the higher priority will run before the process with the lower priority while the process

with the same priority will share the processor time.

As the part of this assignment different scenarios are created and number of context

switches for each process is analysed.

3.2 Design of user space scenarios

There are seven scenarios are created and documented. Which includes the two IO or CPU

bound process with same or different priority.



Scenario 1: Two CPU bound processes with default priority

CPU bound process is the one which works in the back ground. In other words it is not

dependent upon the IO. Here two CPU bound process is created to add two values for couple of

time. This process is created with the default priority. In the case of Linux Default priority is zero.

Scenario 2: Two IO bound processes with default priority

Two IO bound process, which waits for the user input in the type of character .after taking

the input from user this process prints inserted character for couple of times on the screen. These

two processes are created with the Default priority.

Scenario 3: One CPU and one I/O bound process with default priority

In this case one CPU bound process is created which can add two numbers and one IO

bound process which take a character from user to print of the screen for couple of times. Here,

both processes are considered as the default priority.

Scenario 4: Two CPU bound processes with different priorities

Here, two CPU bound process is created which add two numbers for couple of times. The

above created process is with the default priority but in this case the priority of the process is

statically assigned different.

Scenario 5: Two I/O bound processes with different priorities

Here in two IO bound process, which takes priority of the process from user .It dynamically

assign priority to the process.

Scenario 6: One CPU bound and one I/O bound process with higher priority for CPU bound

process and lower priority for I/O bound process

In this scenario one CPU bound process, which add a number for couple of time and one IO

bound process, which takes a priority from user. In this scenario, priority of CPU bound process is

statically assigned to -10. IO bound process assigns priority dynamically. User should enter priority

grater then -10.

Scenario 7: One CPU bound and one I/O bound process with lower priority for CPU bound

process and higher priority for I/O bound process

In this scenario one CPU bound process, which add a number for couple of time and one IO

bound process, which takes a priority from user. In this scenario, priority of CPU bound process is

statically assigned to +10. IO bound process assigns priority dynamically. User should enter priority

less then 10.Lower the priority value, higher the priority.



3.3 Implementation of the scenarios & Results

For implementing scenarios which is explained in the above section, programming language

„c‟ is used. Every „c‟ program starts with the main() function. In Linux, main function is creating a

process with a default priority. By default priority of Linux process is zero.

Scenario 1: Two CPU bound processes with default priority

Snippet 3.1 shows the two different CPU bound processes. Process 1 which is shown in left

plain of snippet and the process 2 which is in right plain. Process 1 is adding 1 to the value of

integer a for 9000000 times. On the other side process 2 is adding 1 to the value of integer a for

300000.Both process is a child process is the bash shell process so both have same priority.

Snippet 3. 1 CPU bound with same priority

Snippet 3. 2 Execution of two CPU bound processes

At the end of the programme the system call which is designed and developed above is

called. And the return value of that system call is printed by the application programme. This

programme is complied in the GCC compiler and executed. Snippet 3.2 shows the output of the two



executed programme. The first two context switches (voluntary & involuntary) is retried by user

application from the local structure and second two values are the return value of the two system

calls for current running process.

Scenario 2: Two IO bound processes with default priority

Snippet 3.3 shows the two different IO bound processes. Process 1 which is shown in left

plain of snippet and the process 2 which is in right plain. Process 1 will ask a character from user

and it prints for five times right side and five times left side. On the other side process 2, will take

one character from user and prints present inserted and next character to right side and present

inserted and previous character on left side .Both process is a child process is the bash shell process

so both have same priority.

Snippet 3. 3 IO bound with default priority

Snippet 3. 4 Execution of two IO bound process

At the end of the programme the system call which is designed and developed above is

called. And the return value of that system call is printed by the application programme. This



programme is complied in the GCC compiler and executed. Snippet 3.4 shows the output of the two

executed programme. The first two context switches(voluntary & involuntary) is retrieved by user

application from the local structure and second two values are the return value of the two system

calls for current running process.

Scenario 3: One CPU and one I/O bound process with default priority

Snippet 3.5 shows the one CPU bound and one IO bound process. Process 1 which is shown

in left plain of snippet and the process 2 which is in right plain. Process 1 is adding 1 to one integer

named a. On the other side process 2, will take one character from user and print inserted character

to the terminal. .Both process is a child process is the bash shell process so both have same priority.

Snippet 3. 5 One IO bound one CPU bound with default priority

Snippet 3. 6 Execution of One IO bound one CPU bound with default priority

At the end of the program, the system call which is designed and developed above is called,

and the return value of that system call is printed by the application program. This program is



complied in the GCC compiler and executed. Snippet 3.6 shows the output of the two executed

program. The first two context switches (voluntary & involuntary) is returned by user application

from the local structure and second two values are the return value of the two system calls.

Scenario 4: Two CPU bound processes with different priorities

Snippet 3.7 shows the two different CPU bound processes. Process 1 which is shown in left

plain of snippet and the process 2 which is in right plain. Process 1 is adding 1 to one integer named

a. On the other side process 2, will take one character from user and print inserted character to the

terminal. Both processes is a child process is the bash shell process so both have same priority

initially. By using the setpriority() the priority has been changed. The priority of the process 1 is

set to 10 and process is stet to 0.

Snippet 3. 7 CPU bound with different priority

At the end of the program, the system call which is designed and developed above is called,

and the return value of that system call is printed by the application program. This program is

complied in the GCC compiler and executed. Snippet 3.8 shows the output of the two executed

program. The first two context switches (voluntary & involuntary) is returned by user application

from the local structure and second two values are the return value of the two system calls.

Scenario 5: Two I/O bound processes with different priorities

Snippet 3.9 shows the two different IO bound processes. Process 1 which is shown in left

plain of snippet and the process 2 which is in right plain. Process 1 is asks priority from the user

and it will assign priority dynamically. After assigning the priority the process will print character

on the screen with the assigned priority. On the other side process 2 will asks the priority from the

user and dynamically it will assign priority. Process 2 will print two characters on the screen. Both

processes are child process of the bash shell process so both have same priority initially.

After using set priority instruction priority of the process will change. At the end of the

program, the system call which is designed and developed above is called, and the return value of



that system call is printed by the application program Snippet 3.11 shows the output of the two

executed program.

Snippet 3. 8 Execution of two CPU bound process with different priority

The First two context switches (voluntary & involuntary) is returned by user application

from the local structure and second two values are the return value of the two system calls. The

priority of the processes is set to 8(for first process) and -1(for second process).

Snippet 3. 9 Two IO bound with different priority

Scenario 6: One CPU bound and one I/O bound process with higher priority for CPU bound

process and lower priority for I/O bound process

Snippet 3.10 shows the one IO bound and one CPU bound processes. Process 1 which is

shown in left plain of snippet and the process 2 which is in right plain. Process 1 will run arithmetic

operation on the priority of -1. On the other side process 2 will asks the character from the user.



Process 2 will print two characters for couple of times on the screen. Both processes is a child

process is the bash shell process so both have same priority initially. After using set priority

instruction priority of the process will change but process 2 is running with the same priority. At the

end of the program, the system call which is designed and developed above is called, and the return

value of that system call is printed by the application program Snippet 3.12 shows the output of the

two executed program

Snippet 3. 10 : One CPU bound and one I/O bound process with different priority

Snippet 3. 11 Execution of Two IO bound process with different priority



Snippet 3. 12 Execution of One CPU bound and one I/O bound process with different priority

Scenario 7: One CPU bound and one I/O bound process with lower priority for CPU bound

process and higher priority for I/O bound process

Snippet 3.13 shows the one IO bound and one CPU bound processes. Process 1 which is

shown in left plain of snippet and the process 2 which is in right plain.

Snippet 3. 13 One CPU bound and one I/O bound process with lower priority for CPU bound

process

Process 1 will run arithmetic operation on the priority of 10. On the other side process 2 will

asks the character from the user. Process 2 will print two characters for couple of times on the



screen. Both processes are a child process is the bash shell process so both have same priority

initially. After using set priority instruction priority of the process will change but process 2 is

running with the priority of -1. At the end of the program, the system call which is designed and

developed above is called, and the return value of that system call is printed by the application

program Snippet 3.14 shows the output of the two executed program.

Snippet 3. 14 Execution of 13 One CPU bound and one I/O bound process with lower priority

for CPU bound process

3.4 Tabulation of obtained results

Table 3.1 shows the tabular representation of the obtained results for all scenarios.

Abbreviation which is used in the table is shown below.

P1 refers to process 1

P2 refers to process 2

Prio_P1 refers to priority of process 1

Prio_P2 refers to priority of process 2

Vol_p1 refers to number of voluntary context switches of process 1

Invol_p1 refers to number of voluntary context switches of process 1

Vol_p2 refers to number of voluntary context switches of process 2

Invol_p2 refers to number of voluntary context switches of process 2



Table 3. 1 Obtained results

Type

of

process

P1 P2 Prio_P1 Prio_P2 Vol_P1 Invol_P2 Vol_P2 Invol_P2

IO 0 0 1 2 1 3

CPU Y Y

IO Y Y 0 0 19 1 34 1

CPU

IO Y 0 0 1 2 19 1

CPU Y

IO 10 0 1 3 1 2

CPU Y Y

IO Y Y 8 -1 19 0 34 1

CPU

IO Y 10 -1 11 1 33 1

CPU Y

IO Y -1 10 11 3 33 1

CPU Y

3.5 Analysis of obtained result

From the above results I can say that, CPU bound process tend to run until they are

preempted because they do not depend on waiting while I/O requests very often do. Because they

are not I/O-driven, however, system response does not dictate that the scheduler run them often.

The scheduler policy for processor-bound processes, it tends to run such processes less

frequently but for longer periods. That can be identified from above table. The scheduler policy in

Unix/Linux variants tends to explicitly favor I/O-bound processes. The scheduling policy in a

system must attempt to satisfy two conflicting goals: fast process response time (low latency) and

high process throughput. To satisfy these requirements, schedulers often employ complex

algorithms to determine the most worthwhile process to run, while not compromising fairness to

other, lower priority, processes.

Favoring I/O-bound processes provides improved process response time, because interactive

processes are I/O-bound. Linux, to provide good interactive response, optimizes for process

response (low latency), thus favoring I/O-bound processes over processor bound processors. As you

will see, this is done in a way that does not neglect processor-bound processes.



From the above tabulated results it is evident that the number of involuntary context

switches made by kernel has changed with change in priority. In both cases with both I/O (scenario

2 & 5) or both CPU bound process with priority (scenario 1 & 4) the number of involuntary

switches have decreased showing that change in priority made them execute for longer time slice.

The Linux kernel implements two separate priority ranges. The first is the nice value, a

number from –20 to 19 with a default of zero. Larger nice values correspond to a lower priority.

Processes with a lower nice value (higher priority) run before processes with a higher nice value

(lower priority). The nice value also helps determine how long a time slice the process receives. A

process with a nice value of –20 receives the maximum time slice, whereas a process with a nice

value of 19 receives the minimum time slice.

In cases with priority (Scenario 3 & 6, 3& 7) the number of switches has changed due to the

introduction of sleep function in CPU bound process so the number of voluntary switches remained

almost the same.

3.6 Suggestion for improvement of context switch mechanism in Linux

From the above analysis I can suggest that, Linux scheduler has a list called the run queue

containing all contexts ready to run. These contexts are not sorted in any way. Each context also has

a priority. Two loops are within the scheduler. The first loop (the searching loop) finds the context

with the highest priority from the ready queue and selects that context to run. The second loop (the

recalc loop) recalculates the priorities if all contexts have used their entire time slice. This second

loop runs only occasionally. Snippet 3.15 shows the scheduling mechanism of the Linux.

Snippet 3. 15 Schedule logic of Linux

The search loop needs a small bit of CPU time for every runnable process and needs it on

every context switch. . Generally, there will be only a few (perhaps one to three) contexts to choose



from. Most processes and threads, even very active ones, will be waiting for some I/O event to

occur and are, therefore, not on the ready queue and not considered for selection.

The recalc loop runs only when every context on the ready queue has used up its entire time

slice (generally 20 ticks or 0.2 seconds). The recalc loop then recalculates the priority of each

context. Normally, this recalc loop runs only occasionally. Most rescheduling is done in response to

an interrupt or because of an I/O request; therefore, most contexts do not use their whole time slice.

However, when a process or thread wants to yield the CPU, it calls sched_yield, which treats it as if

the process had used its entire time slice.

In this way, any process that calls sched_yield has its priority lowered and will not be

scheduled again for a substantial period of time. When all contexts have used their entire time slice,

the scheduler recalculates the priority of all contexts using the recalc loop. Since during this point

all contexts do one cheap operation (sched_yield) and then a counter set to zero, this recalc loop

runs much more often than normal. Again, this moment seems to be a worst case for Linux.

3.7 Conclusion

In this part the, as per the requirement seven different scenarios (processes) are created and

the system call which is designed in part b is used to get the number of context switches for each

process. Scheduling of the kernel scheduler for processes with different priorities is tabulated in this

chapter. Analysis for the number of context switches for different process is documented as the part

of this work.



CHAPTER 4

____________________________________________________________

4.1 Module Learning Outcomes

This module helped me to understand the changing of the kernel version in Linux.

This module (Advanced System programming) helped me to understand the modular design

of Linux kernel and the concepts user defined modules to access privilege data structures in

Linux.

Linux kernel keeps track of the all the data related to hardware and running process to

provide an abstraction from user. After completion of this module I came to know about the

three ways to access this privileged data from user mode. The first way is /proc file system,

system call and loadable kernel module.

File system is the methodology to organize/manage files/Directories. In this module I came

to know about Linux file system and kernel data structure regarding to files/Directories.

Linux is a multi-tasking operating system. To achieve a multi-tasking feature, contest

switches between processes in essential. On the successful completion of this assignment I

came to know about approach of the Linux kernel with the different type of processes with

different priority.

Part c of this assignment helped me a lot to develop clear understanding about Linux

scheduling process.



References

____________________________________________________________

[1] http://www.naun.org/journals/computers/17-372.pdf

[2] Linux File Systems: Ext2 vs Ext3 vs Ext4 by Ramesh Natarajan on may 16, 2011

[3] Ext4 file system Performance Analysis in Linux Environment BORISLAV DJORDJEVIC,

VALENTINA TIMCENKO, Mihailo Pupin Institute ,University of Belgrade Volgina 15,

Belgrade SERBIA

[4] The new ext4 filesystem: current status and future plans, Avantika Mathur, Mingming Cao,

Suparna Bhattacharya ,IBM Linux Technology Center

[5] http://hekimian-williams.com/?p=20

[6] http://linuxgazette.net/133/saha.htm



Appendix ________________________________________________________________________________

1.4.1a: File operations with transactions

1.4.1b: File operations without transactions


assignment 4

Technology

new system

developed system calls

submission of assignment

advance system programmingiii

monolithic software

assignment reports

kernel information

improvement of ext file