Betriebssysteme/hw5/simu2/ANSWERS.md

Antworten

1. Figure 8.1: A Single Long-Running Job

./mlfq.py -l 0,200,0

Dieser Aufruf erzeugt einen Job der bei Zeit t=0 startet, 200ms läuft und keine IO-Time hat.

Figure 8.2: Along Came a Short Job

./mlfq.py -l 0,200,0:120,20,0

Job 0 startet bei t=0 mit 200ms Runtime und Job 1 springt bei t=120 für 20ms ein (10 ms Priority 2 + 10ms Prority 1). Wenn man nun das “alte” t=20 als neuen Zeitpunkt 0 sieht, dann hat man das Beispiel aus der Vorlesung.

Figure 8.3: What About I/O?

./mlfq.py --jlist 0,180,0:100,20,0 -Q 10,10,10

Figure 8.4: A Mixed I/O-intensive and CPU-intensive Workload

Figure 8.5: Without Priority Boost    ./mlfq.py -S -l 0,100,0:100,50,5:100,50,5

  Figure 8.5: With Priority Boost    ./mlfq.py -S -l 0,120,0:100,50,5:100,50,5 -B 50

**Figure 8.6: Without Gaming Tolerance**

   

**Figure 8.6: With Gaming Tolerance**

   

1. Indem man den Scheduler mit -m 1 auf nur eine Queue einstellt. Dann werden neue Jobs nicht in eine höhere Queue gestuft und die Priorität auch nicht erhöht.

2. Mit dem Aufruf ./mlfq.py -S -l 0,200,0:0,800,99 -c -q 100 -i 1 wird der erste Job bei t=100 von dem 2.ten zu 99% unterbrochen, welcher Regel 4b ausnutzt und auf Priorität 2 bleibt. Man sieht dass JOB 1 99 Ticks läuft, dann darf JOB 0 ein Tick arbeiten und der Kreislauf wiederholt sich:

[ time 198 ] Run JOB 1 at PRIORITY 2 [ TICKSLEFT 1 RUNTIME 800 TIMELEFT 701 ]
[ time 199 ] IO_START by JOB 1
IO DONE
[ time 199 ] Run JOB 0 at PRIORITY 1 [ TICKSLEFT 99 RUNTIME 200 TIMELEFT 99 ]
[ time 200 ] IO_DONE by JOB 1
[ time 200 ] Run JOB 1 at PRIORITY 2 [ TICKSLEFT 99 RUNTIME 800 TIMELEFT 700 ]
[ time 201 ] Run JOB 1 at PRIORITY 2 [ TICKSLEFT 98 RUNTIME 800 TIMELEFT 699 ]
[ time 202 ] Run JOB 1 at PRIORITY 2 [ TICKSLEFT 97 RUNTIME 800 TIMELEFT 698 ]

1. 1wsw >>YYA
2. Bei Workloads bei denen mehr als ein Job auf einer Queue läuft hat diese Option ein Effekt.