

Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
A programming assignment for ecs-251, winter 2009, where students are required to modify the freebsd 5.x kernel to implement lottery scheduling. The assignment involves adding new attributes and system calls, and writing test programs to demonstrate the effects of lottery scheduling. Students are expected to follow good coding conventions and ensure that their implementation distributes cpu cycles to processes according to the lottery scheduling principle.
Typology: Assignments
1 / 2
This page cannot be seen from the preview
Don't miss anything!


ECS-251, Winter 2009, Programming Assignment # Due date: the interactive grading appointment around 01/23/ Total 10% Lottery Scheduling in the FreeBSD 5.x Kernel This assignment is related the “lottery scheduling” algorithm in FreeBSD 5.4 kernel. Please make sure that you follow a good coding convention. You need to provide a Makefile and a README.txt. And, most importantly, you will need to develop some test programs to demonstrate the effects of lottery scheduling. Modify the FreeBSD 5.x kernel such that the users can give different amount of lottery tickets to each “user” process. Please note that you do not need to worry about “lottery ticket sharing” case – just the simplest form of lottery scheduling. We still maintain different levels of priorities as in FreeBSD, but you need to implement TWO different options: (1). The lottery mechanism will be placed ONLY in the real-time and time-sharing scheduling class (i.e., priorities 128~223). (2). The lottery mechanism will be placed also in higher scheduling classes (i.e., priorities 0~223). In other words, you need to give kernel classes more tickets to start with such as 128 (lower kernel), 32 (high kernel), 8 (real-time), 4 (time-share), 1 (otherwise). You will need to add one new attribute “int tickets” into “struct proc” defined in “/usr/src/sys/sys/proc.h”, and one global variable “int lottery_mode” in “/usr/src/sys/kern/kern_switch.c”. And, you will need to add the following four system calls: int setProcessTickets(int pid, int tickets); int getProcessTickets(int pid); int setLotteryMode(int mode); int getLotteryMode(void); First, by default, each user process in the time-sharing class has four tickets, while a user program can set the ticket number differently using the setProcessTickets system call. Second, your kernel use “normal BSD scheduling” by default, and the amount of tickets in each process makes no impact to the scheduling behavior. However, when a user process sets the lottery_mode to 1 (via the setLotteryMode system call), the kernel changes its scheduling behavior immediately to “lottery scheduling”. The original Lottery Scheduling can be found at: http://www.usenix.org/publications/library/proceedings/osdi/full_papers/waldspurger.pdf Your team will need to write a couple test programs to test whether your implementation distributes CPU cycles to the process according to the lottery scheduling principle.
Furthermore, to simplify the task, we assume that all KSEs (or kernel threads) will obtain exactly the same number of tickets being assigned to its process. Among possibly others, you will likely to modify a few kernel source files such as: kern/kern_switch.c kern/kern_fork.c sys/proc.h In the proc.h file, please add a new attribute “tickets” to struct proc, and also, a global variable declaration “lottery_mode” to indicate whether the lottery scheduler is on or not (0: off, 1: on). Interactive Grading policy: 01: attending the interactive grading session 02: compiled kernel and loadable modules 04: implemented Lottery scheduling, but kernel crashes/freezes 05: occasionally kernel panic/freezing, but lottery scheduling will run in most of the cases 07: the effect of lottery scheduling is reasonably clear with good explanation and no kernel panic 09: functionally correct for all the requirements, and both your and my test programs will run OK. 10: the test programs are "creative and impressive" very nice/smooth demo with some extra ideas/features demonstrated. Furthermore, one or both of your submitted test programs can crash/panic other submitted kernels in some non-trivial way. Bonus: if your test program can knock down more than half of the submitted kernels (other than yours), you will can one extra bonus point.