Minix 3 Final Project Report

Final Project Report -- Lottery scheduling in user mode on Minix 3

Author: Tingting Xu, Yuanyuan Xie, Haitao Huang
Professor: Dr. Yang
Course: COEN 283 Operating System

Abstract

This document describes the final project for the course COEN 283 – Operating System. The project is team oriented, main goal is to select a topic related the Operating System concepts that should be either theoretical, in which new algorithm is analysis and simulate, in which subsystem/driver of an OS is prototyped. Provide the simulation/implementation code and explain the detail design in this report. This project will provide opportunity for students to perform research on topic of interest of operating system.

The selection of the next process to give the cpu to is done in kernel/proc.c, and uses 16 ready queues to control priority. The first process in the first non-empty queue is chosen to run next; therefore if there is always a runnable process in queue 0, no other queue will have processes run from it. The scheduling of processes into different queues is done by the sched server (servers/sched/*). The current sched algorithm uses a simple algorithm where each process has a maximum priority, and the priority is decreased every time the process gets a turn, and increased periodically towards the maximum priority (using a timer). In the current system, a process can use the nice () system call to increase or decrease its maximum priority.
Every time a lottery is held, the scheduler should randomly select a ticket (by number), and then boost the priority of the process holding that ticket. The ticket selected should clearly be between 0 and one less than the total number of tickets. The scheduler should also regularly reduce the priority of processes. If a process wins many of the lotteries, they will have a lower (higher priority) average queue, whereas a process that wins fewer lotteries will have a higher (lower priority) average queue, and thus the amount of cpu time each process gets will be

We intended to make our scheduling policy- lottery scheduling on the server side.
Lottery algorithm

➢ We add 3 more queues in kernel. This will make a place for our lottery scheduling. System processes (queues 0–14) are run using their original algorithm, and queue 15 still contains the idle process. Queues 16 - 18 are newly appended for our scheduler. This is the only modification in kernel.
➢ The newly appended queues 16-18 in our scheduler then are used like this: when a process starts, we put it to queue 17; when there is a process run out of quantum, we put it to queue 17, and a lottery draw takes place right after that, which would put a winner to queue 16.
➢ Since in the kernel side policy a highest priority process that is runnable, process in queue 16 would be chosen and those in lower priority queue 17 would be ignored. Processes in queue 17 would be ignored.
➢ This is what we expect because we would only put a lottery winner in queue 16, and move it away right after when it runs out of quantum. Figure -3: Design for process flow
In schedule.c we add 2 more functions, do_lottery() and