developersguide:userspacescheduling
Differences
This shows you the differences between two versions of the page.
| Next revision | Previous revision | ||
|
developersguide:userspacescheduling [2014/11/11 14:52] 127.0.0.1 external edit |
developersguide:userspacescheduling [2017/06/02 16:31] (current) shtjonathan [Advantages over the in-kernel scheduler] minor syntax edits |
||
|---|---|---|---|
| Line 2: | Line 2: | ||
| ==== How does it work? ==== | ==== How does it work? ==== | ||
| - | Scheduling in Minix is simple multi-priority round robin. Each runnable processes in a its priority queue and has a quantum assigned. The assigned quantum of each process is periodically decreased. Each process is associated with a scheduler, e.g. a process that is responsible for making scheduling decisions for such a process. | + | Scheduling in Minix is simple multi-priority round robin. Each runnable process is in a priority queue and has a quantum assigned. The assigned quantum of each process is periodically decreased. Each process is associated with a scheduler, e.g. a process that is responsible for making scheduling decisions for such a process. |
| - | The //kernel// retains a very simple round robin scheduler which always picks the process at the head of the highest priority queue. This does not guarantee that processes will not starve. It also contain a default policy. If a process is not associated with any userspace scheduler and runs out of its quantum the quantum is renewed. If a process is associated with a scheduler a message generated by the kernel on behalf of the process is sent to the scheduler every time the process runs out of its quantum. Process that runs out of its quantum is blocked (not runnable) until the scheduler decides. | + | The //kernel// retains a very simple round robin scheduler which always picks the process at the head of the highest priority queue. This does not guarantee that processes will not starve. It also contains a default policy. If a process is not associated with any userspace scheduler and runs out of its quantum, the quantum is renewed. If a process is associated with a scheduler, a message generated by the kernel on behalf of the process is sent to the scheduler every time the process runs out of its quantum. A process that runs out of its quantum is blocked (not runnable) until the scheduler decides. |
| The scheduler can change the process priority and time quantum. //sys_schedule()// is used to change the priority and quantum and thus can make the process runnable again. | The scheduler can change the process priority and time quantum. //sys_schedule()// is used to change the priority and quantum and thus can make the process runnable again. | ||
| - | The userspace scheduler can use //sef_receive_status() //to check whether the message was generated by the kernel or whether the massage is a fake sent by a processes. This information is reliable. | + | The userspace scheduler can use //sef_receive_status()// to check whether the message was generated by the kernel or whether the massage is a fake sent by a process. This information is reliable. |
| ==== Advantages over the in-kernel scheduler ==== | ==== Advantages over the in-kernel scheduler ==== | ||
| - | No need to make any changes in the kernel if a different scheduling policy is required. The ability to change the priority and time quantum allows implementation of wide range of scheduling algorithms | + | No need to make any changes in the kernel if a different scheduling policy is required. The ability to change the priority and time quantum allows implementation of a wide range of scheduling algorithms |
| ==== Current status ==== | ==== Current status ==== | ||
| SCHED is the //userspace// scheduler for most processes. The some core system processes are scheduled by kernel using the default policy. You can find the details of the design and implementation in the projects final [[http://www.minix3.org/docs/scheduling/report.pdf|report]] by Bjorn Swift | SCHED is the //userspace// scheduler for most processes. The some core system processes are scheduled by kernel using the default policy. You can find the details of the design and implementation in the projects final [[http://www.minix3.org/docs/scheduling/report.pdf|report]] by Bjorn Swift | ||
developersguide/userspacescheduling.1415713928.txt.gz · Last modified: 2014/11/11 14:52 by 127.0.0.1
