Due 11:59 PM, Friday, April 15, 2016
In this lab you will experiment with different scheduling policies in xv6. Specifically, you will implement the lottery scheduling policy.
If you want to build upon your copy-on-write fork, you may. However, you are also welcome to create a new branch based on the unmodified xv6 code.
When you are ready to hand in your lab code and write-up, create a file called slack.txt noting how many late hours you have used both for this assignment and in total. (This is to help us agree on the number that you have used.) This file should contain a single line formatted as follows (where n is the number of late hours):
Late Hours Taken for Lab 1: x Late Hours Taken for Lab 2: y Late Hours Taken for Lab 3: z Late Hours Taken for Lab 4:
Then run make handin-lab4 in the xv6 directory. If you submit multiple times, we will take the latest submission and count late hours accordingly.
In this and all other labs, you may complete challenge problems for extra credit. If you do this, please create a file called challenge.txt, which includes a short (e.g., one or two paragraph) description of what you did to solve your chosen challenge problem and how to test it. If you implement more than one challenge problem, you must describe each one.
This lab does not include any questions for you to answer, but you should document your design in the README file.
Start by reading Chapter 5 of the xv6 book. This is a very good guide to the details of how scheduling and context switches are implemented in xv6. The default and only scheduling policy in xv6 is round-robin. In other words, every runnable process gets an equal CPU timeslice, regardless of priority.
Your goal for this homework is to create a framework for expressing priorities, as well as implement the lottery scheduler to support these priorities. You will also need to write several test cases to demonstrate that your system implements these policies correctly.
The first step in implementing a non-trivial scheduler is to actually have policies. In order to keep the homework simple, you may just implement the nice Unix API as an extra system call. Remember, a higher nice value means a lower priority. For more on the nice specification, type man 2 nice on a Linux system.
This should be a very straightforward exercise after lab 1, except that you will also need to store the nice value in the process structure. Note that xv6 stores the process control block (PCB, or PEB in Windows parlance, or task struct in Linux parlance) in struct proc in the file proc.h.
Simplification: You do not need to enforce permissions on nice. On a typical Linux system, only root can increase priorities (lower nice values); to keep life simple for this project, you can skip this part of the specification.
Hint: nice is specified as a "set" method, but there is a way to also "get" the current value with clever argument selection. Be sure this works on your system.
Exercise 1. (5 points) Implement the nice system call in xv6. Write a simple test case to verify that the nice value can set and be read back correctly. Document how to run this test in a file named README.lab3.
Lottery scheduling is a randomized heuristic. This does not require strong randomness, as may be need for cryptographic algorithms---a decent pseudo-random number generator (PRNG) will do. Because xv6 does not include a PRNG, you will need to write one.
For your implementation, we recommend something in the Xorshift family, although you are welcome to use others.
Hint: If you do use Xorshift, be very careful to pick non-zero seed values.
Exercise 2. (5 points) Implement an in-kernel pseudo-random number generator. Write a simple, in-kernel test case to verify that the values returned look reasonably evenly distributed over the value space. Document how to run this test in a file named README.lab3.
Challenge! (up to 25 points, depending on solution quality) Implement a true random number generator, suitable for use in a cryptographic algorithm. True randomness is hard, and requires both sophisticated algorithms and a pool of entropy from external sources, such as non-deterministic hardware events (e.g., mouse movement, keystrokes, and heat).
As explained in the course slides, as well as Chapter 9 of the OS book, lottery scheduling basically works by assigning numbers (tickets) to each process in the system, and then randomly picking a "winning" ticket each timeslice. You may decide (and document in README.lab3) a policy for how many more tickets to assign less "nice" processes, and vice versa.
From here, the design of the scheduling data structures is somewhat open-ended. As you read the book and think about your design, some factors to consider: How to map the winning number back to a runnable process? What data structure makes sense? How would you gracefully handle proceses leaving or entering the system, while maintaining the policy?
Simplification:Please keep both schedulers as options. For simplicity, it is fine for the scheduler selection (lottery vs. RR) to be a compile-time option, although a few bonus points are availble if a group wishes to implement the ability to dynamically select between scheduling algorithms.
Exercise 3. (40 points)
Implement lottery scheduling in xv6. As explained above, the particular
selection of data structures and policies for mapping the number of tickets
to nice values is up to you.
An important aspect of this project is convincing the course staff that your
implementation handles all of the reasonable edge cases, so please err
on the side of writing extensive documentation (even "what if?" questions and answers)
in the README.lab3 file.
Exercise 4. (10 points)
Write at least three good test cases (although more are strongly
recommended) for your lottery scheduler. Extra credit is possible for creativity,
and the quality of these tests can influence your score for Exercise 3.
Some suggestions and hints:
Challenge! (up to 5 points, depending on solution quality) Implement the ability to dynamically select between the round-robin scheduler and the lottery scheduler. Be sure that policies are correctly enforced when switching back and forth (e.g., nice values or "tickets" are not lost or mis-allocated when switching).
Challenge! (up to 20 points, depending on solution quality) Implement the multi-level feedback queue scheduler, as described in Chapter 8 of the OS book. Be sure to add enough (optional) debug prints and documentation to be sure that the algorithm is working correctly, and design test cases that demonstrate that, as nice values change, the number of quanta assigned changes appropriately.
This completes the lab. Make sure you hand in your work with make handin-lab4.
Last updated: 2016-05-10 19:16:55 -0400 [validate xhtml]