Scheduling Policy - Minix

This is a discussion on Scheduling Policy - Minix ; Hi! We don't get scheduling policy we hugged source code for at least one hour, but we just don't get it. The penalty system is used to prevent lower priority processes from starving. A penalty is applied if a process ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Scheduling Policy

  1. Scheduling Policy

    Hi!

    We don't get scheduling policy we hugged source code for
    at least one hour, but we just don't get it.

    The penalty system is used to prevent lower priority processes from
    starving. A penalty is applied if a process is run twice in a row.
    Now assume that two processes run at priority 2 and a couple of others
    run at priority 7.
    The priority 2 processes will be choosen alternatingly and thus neither
    would receive a penalty. Since if a time quantum is used up the process
    is enqueued at the end of the priority queue. Given this none of the
    priority 7 processes will be scheduled for running unless one priority 2
    process terminates (the other would be schedules repeatedly and
    penalized up to level 7).

    Somehow we wonder why using penalties at all if it only affects a single
    high priority process.

    Did we get something wrong or this simply a strange algorithm?

    Bernhard

  2. Re: Scheduling Policy

    Bernhard Kast wrote:
    > We don't get scheduling policy we hugged source code for
    > at least one hour, but we just don't get it.
    > ...
    > Did we get something wrong or this simply a strange algorithm?


    True. The scheduling code is work in progress. Multiple priority queues
    are in place, but a proper feedback mechanism to degrade or upgrade the
    priority of processes is not. We want to have a heuristic that punishes
    CPU-bound processes and rewards I/O bound processes. In the next release
    this problem should be solved. I have some ideas, but they have not been
    tested.

    One possibility is as follows. Each process has a fixed maximum priority
    and a current priority that determines what queue it currently is in.
    Processes that consume a full quantum will degrade in priority. Perhaps
    there should be a lower bound based on the maximum priority. A priority is
    upgraded one point (unless already at the maximum) when a process that was
    blocked due to I/O gets ready. Whenever the priority is changed a new
    quantum is given.

    One can check the bill pointer to find out whether a process blocked due
    to I/O or due to some other system call. The reasoning here is that the
    bill pointer will point to a different user process B or IDLE, when a user
    process A gets ready after being blocked due to I/O.

    While this may work to schedule user processes, it does not help for
    system processes as they don't have a bill pointer. One thing that is on
    my mind is to use priority inheritance for system processes, but this may
    introduce unexpected problems. I'm open to comments and suggestions on
    this matter.

    Jorrit

+ Reply to Thread