The objective of this project is to add a new scheduling algorithm to the Linux Kernel and write modules and driver programs to test these changes.
The PHB at AWK wants to create a standalone product that runs middleware on top of linux. The latest SE magazine that he subscribes to had an article about how a custom scheduling algorithm can really make the product run consistently on top of the underlying operating system. Ignorant of the real time scheduling abilities already available in the linux kernel, he wants you to write your own priority scheduling algorithm modification into the kernel.
Before you begin, create a custom kernel specific for Project 2 by copying the pristine sources to a new folder, e.g. /usr/src/linux-prj2, and changing the symbolic link /usr/src/linux to point to it.
Hereafter let $linux stand for the /usr/src/linux directory with the experimental kernel sources.
Groups: Students may form groups of up to 3 students and possibly 4 with special permission. You may use the discussion board to find a group. You may make your changes and drivers together, but your project reports must be the sole result of your own effort. Duplicating text or results is not permitted!
Version Control: To track your progress, the TAs will set up a subversion repository for each group. Once you have formed your group please contact the TAs for details.
Along with SCHED_FIFO, SCHED_RR, and SCHED_OTHER, you will add SCHED_PRIO to the linux kernel. SCHED_PRIO is a basic round robin priority queue. Priority p ranges from 1-5, and each process under SCHED_PRIO is allotted p time quantums (e.g. a priority 1 process is run for 1 quantum, priority 3 process is run for 3 quantums). The quantum you decide is ultimately up to you.
You will find the scheduling code for the kernel in $linux/kernel/sched.c. Other resources:
Create a loadable kernel module that will create a proc file to allow you to read and change the default quantum that you set in Part 1. The file should be: /proc/prioquantum. Reading it should return the current quantum and writing it should change the quantum. There are no loading parameters for the module.
The best resource for proc is the kernel documentation. Other resources:
Create two drivers. The first will allow you to create new processes with a given priority, similar to how the command nice currently operates. The second will allow you to change the priority of a currently running process.
You may need to add system calls for this part. You may also do it through the procfile of existing processes.
Create a third driver and modify the kernel to hide a process that uses your scheduling algorithm from the process list.
As always, you must answer each question in the questions section of your report. Follow the outline given in Project 1. Your report, and any tests, must be written in your own words or conducted by you on your machine. The report will be graded separately from the rest of the project submission, and you should submit your PDF using submit with the project keycode as in previous projects.
What did each of your group members do? What did you do?
Create (or use preexisting) several test programs. There should at least be one program that does each of the following: Lots of IO Processing (like cp or dd), Lots of CPU Processing (Matrix Calculations), User I/O (interactive driver), and some combination of any of the above. Each process should run for at least a minute.
After you have created your test programs, run them using your new Scheduling algorithm using a standard linux time metric that gives you time info in system overhead and actual process cpu usage (e.g. the time utility). Run 10 of each type, and then a combination of 30 at the same time. Number each process and put the results of at least a dozen tests in a spreadsheet. Run your test for at least 3 different quanta/quantums, and be sure to include the differences in all the results in your final report. Now, compare that with the same tests using a standard linux scheduling system. What did you find? Don't forget to include a complete description of the types of processes that your tests used.
You only need to submit your project report using submit for this project.
Your group needs to produce a patchfile and place it in your SVN repository or e-mail it to the TAs.