Multi-Level Feedback Queue

• How can we balance the benefits of STCF and round robin?
• How do we handle the fact that we don’t know how long jobs will run?

• In other words, how do we minimize turnaround time for CPU-bound jobs, but minimize response time for interactive jobs.

• Key idea: Learn from the past.
• What systems from CIS 351 do this?
  • Cache
  • Branch Prediction
• Basic structure:
  • Multiple queues (Figure 8.1: https://pages.cs.wisc.edu/~remzi/OSTEP/cpu-sched-mlfq.pdf)
  • Within a single queue, processes go round-robin
  • The queues are prioritized: Only take processes from the highest priority non-empty queue.

• A process’s priority can change over time based on its observed behavior.

• What processes should have high priority?
  • Interactive processes
  • Processes that are “starving”.
• How can we determine whether a process is interactive?
  • It blocks often
• Look at Figure 8.1:
  • If Processes A and B are interactive, will C and D necessarily starve?
  • Maybe, but not necessarily. Humans are slow enough that both may be blocked waiting for input that C and/or D get a chance to run.
• Idea:
  • New process starts at high priority.
  • If process uses its entire time-slice without blocking, reduce its priority.
• Look at Figure 8.3
  • Notice how, in the right figure, the grey process is still interactive but has a negligible effect on the total running time of black.
• What are some problems?
• How can we “game” the system?
  • Starvation can occur if there are enough interactive processes.
  • What if a process does a lot of CPU “thinking” then becomes interactive again.
    • Give an example
  • We can game the system by issuing I/O at 99% of the time slice.
    • What exactly is the problem with this? (Besides “unfair”)
    • The “worthless” I/O takes up time/resources, making the system less efficient for everybody in order to benefit one person.
• Priority Boost: Simply re-set everyone to the highest priority periodically.
• How often?
  • No right answer. Set it empirically.
• How can we avoid “gaming” the system?
  • Set a maximum time at each queue level.

Setting time slices

• Should all queues have the same time slice?
• If not, which ones should have short slice and which should have?
  • High-priority queues should have short slices to get interactive jobs back to the CPU as quickly as possible.
  • Low-priority queues have longer slices to provide more efficiency.
• Example: Solaris default values
  • 60 queues
  • time slice times: 20ms to 100ms
  • Boost: every second
• Other options:
  • Reserving highest queues for OS and/or Real-time jobs
  • Allowing users to advice (e.g., nice)

  https://pages.cs.wisc.edu/~remzi/OSTEP/cpu-sched-mlfq.pdf