Lab 1: System calls and scheduler

Handed out Tuesday, Jan. 15, 2019
Due Monday, Feb. 4, 2019

Introduction

There are two parts to this assignment: (1) Add a system call to xv6, and (2) Change the scheduler to use stride scheduling.

Part 0: Setup and getting started

Please follow the setup instructions on the class webpage to get xv6 downloaded, installed and working with qemu and gdb. You may find it helpful to go through this optional xv6/JOS pre-lab

Part 1: Add a new system call

In this part of the assignment, you need to understand the system call implementation and add a new system call info(int type). Repeating from the optional lab:

Open two terminal windows. In one, enter make qemu-gdb (or make qemu-nox-gdb). This starts up QEMU, but QEMU stops just before the processor executes the first instruction and waits for a debugging connection from GDB. In the second terminal, from the same directory you ran make, run gdb. (Briefly, gdb -q -iex "set auto-load safe-path /home/csprofs/nael/xv6-master/" . Change the last part to your path to the xv6 directory. You should see something like this,

sledge% gdb
GNU gdb (GDB) 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu".
+ target remote localhost:26000
The target architecture is assumed to be i8086
[f000:fff0] 0xffff0:ljmp   $0xf000,$0xe05b
0x0000fff0 in ?? ()
+ symbol-file obj/kern/kernel
(gdb)

Now set a breakpoint on exec() by typing break exec in the gdb window type continue You should see something like: 

(gdb) cont
Continuing.
[New Thread 2]
[Switching to Thread 2]
The target architecture is assumed to be i386
=> 0x80100af8 :push   %ebp

Breakpoint 1, exec (path=0x1c "/init", argv=0x8dfffe98) at exec.c:12
12{
(gdb)

Here we stop execution after the OS is initialized at the stage where it is starting the first process (init). If you type continue again, you will break again as follows: 

gdb) cont
Continuing.
[Switching to Thread 1]
=> 0x80100af8 :push   %ebp

Breakpoint 1, exec (path=0x8c3 "sh", argv=0x8dffee98) at exec.c:12
12{

As you can see, at this stage, init started a shell process which is the xv6 shell we get when the OS boots. If you continue again, gdb will not return since it is waiting for a command to be started in the shell. Switch to the other window and try typing a command (fore example, cat README) at which time you will get another break as the shell forks then execs the cat program. Feel free to look around at the program when it breaks to see how we reach the system call which should give you ideas about how to add one.

Assignment for this part

Add a new system call info(int param) that takes one integer parameter with value 1, 2 or 3. Depending on the value, it returns: (1) A count of the processes in the system; (2) a count of the total number of system calls that a process has done so far; and (3) the number of memory pages the current process is using.

Part 2: Implement lottery and stride scheduling

In this part of the assignment, you will implement lottery scheduling as per the OSDI 1994 paper we read in class. Implement only basic operation (no ticket transfers, compensation tickets, etc...). It is up to you to design the interface to assign the number of tickets, but it should be sufficient to illustrate that the scheduler works. Also implement the related stride scheduling which uses the same interface but schedules the process more predictably.

To get started, look at the file proc.c

In there you will find a simple round robin CPU scheduler implemented. You should change the logic there to use lottery scheduling. However, you also need to create the data structures to keep track of tickets.

The specification of this part is intentionally open so that you can think about how to structure the design. For example, you need to design the interface to the scheduler to assign tickets to processors (e.g., using a system call).

For full credit, you should demonstrate that your schedulers work, and have scenarios that illustrate the differences between them. Track performance metrics such as response time and fairness over a number of workloads. Look at the papers for ideas about experiments.

Bonus (10%): Qemu has an option of emulating multi-core system. If intialized with multiple cores, does the scheduler send processes to execute on multiple cores? Propose and demonstrate a scheduler suitable for multi-core scheduling. If you do everything other than the scheduler demonstration (i.e., explain whether the multiple cores are used or not, and show a paper design for a scheduler), you get half the bonus.

Grading Rubric (thanks, Bashar)

Lab1: 110% possible points.

Part 1 (50%): a program that uses a new system call info(int param)

Part 2 (50%) - modify the xv6 scheduler. 

 #include "types.h"
 #include "stat.h"
 #include "user.h"
int main(int argc, char *argv[])
  { 
  FUNCTION_SETS_NUMBER_OF_TICKETS(30);// write your own function here
   int i,k;
   const int loop=43000;
   for(i=0;i <loop;i++)
       for(k=0;k<loop;k++);
               asm("nop");
   exit();
}

The program “prog1.c” has 30 tickets, add “prog2.c” with 20 tickets and “prog3.c” with 10 tickets. Run all of them simultaneously : $ prog1&;prog2&;prog3

When each of these programs finishes execution, your system call should print the number of times the processes was scheduled to run (number of ticks).

When the program with the higher number of tickets finishes first. This is where you display the number of "ticks" that each pf the 3 programs have used up to this point and use it calculate the ratio for each program.

Use the number of tickets to calculate the allocated ratio per process : (number of ticks per program)/(total number of ticks by all 3 programs)

Approximately prog1 ratio will be 1/2 , prog2 ratio will be 1/3 and prog3 will be 1/6.

Stride scheduler (25%)

Similarly, use the same program and run it using three different number of tickets for example (100,50,250) then the stride values are inversely proportional to the number of tickets strides (100,200,40). Results of dividing 10,000 by the number of tickets for each process.

Show that over time:

prog3 will run 5 times more than prog2 & about 2.5 times more than prog1.

prog1 will run about 2 times more than prog 2. Extra credit (10%):

Qemu has an option of emulating multi-core system. If intialized with multiple cores, does the scheduler send processes to execute on multiple cores? Propose and demonstrate a scheduler suitable for multi-core scheduling. If you do everything other than the scheduler demonstration (i.e., explain whether the multiple cores are used or not, and show a paper design for a scheduler), you get half the bonus.

Submission Guidelines

For any line or block of code you add to any file, mark them with the comment (\\cs202)

To make the project size smaller, clean the make files and compress it before submitting it.

$ make clean

$ zip username_lab1_1 /path_to_xv6_flolder

$ zip username_lab1_2 /path_to_xv6_flolder

If you work in a group. put the usernames of all the group members.

Write a report that includes:

For full credit, you should demonstrate that your schedulers work, and have scenarios that illustrate the differences between them. Track performance metrics such as response time and fairness over a number of workloads. Look at the papers for ideas about experiments.

Upload all zip files and report (PDF file) to ilearn.

There will also be a (10-12) minutes demo, available time slots will be announced soon.