githubgossin
commented
3 years ago Agree, I made a pull request before I saw this issue where I ask:
Is this really correct for the figure on the right:
- why does the long-running job not get boosted after the first 50ms?
- why do the short-jobs get to run five times each before the long job? shouldnt they circulate in RR-fashion?
- the last run of the long job happens before the priority boost at 200ms so that run should be in Q1 I think
forgive me if Im missing something here
(also trying to run this example with the simulator with something like mlfq.py -Q 10,10,10 -l 0,130,0:100,30,1:100,30,1 -i 1 -S -B 50 seems to give very strange results, the boost at time 50 lets the process just run once at level 2, then 10 times at level 1, the simulator seems a bit messed up wrt Q2)
remzi-arpacidusseau
I am looking at the right side of the diagram of figure 8.5 that shows 3 running processes, two of which have I/O. The paragraph describing the figure says
"Let’s see an example. In this scenario, we just show the behavior of a long-running job when competing for the CPU with two short-running interactive jobs. Two graphs are shown in Figure 8.5 (page 6). On the left, there is no priority boost, and thus the long-running job gets starved once the two short jobs arrive; on the right, there is a priority boost every 50 ms (which is likely too small of a value, but used here for the example), and thus we at least guarantee that the long-running job will make some progress, getting boosted to the highest priority every 50 ms and thus getting to run periodically."
However, the diagram shows process A getting its first priority boost at time ~120. Shouldn't it be boosted to from q0 back to q2 at time 50, before the other two processes start at time 100?