|
|
@@ -1,3 +1,4 @@
|
|
|
+\newpage
|
|
|
# Ejercicio 9
|
|
|
|
|
|
Implementamos este ejercicio utilizando:
|
|
|
@@ -20,10 +21,13 @@ Cada vez que se carga un nuevo proceso, el mismo se aloja en la cola de mayor pr
|
|
|
Al haber un _tick_ se controla que no se haya cumplido el _quantum_ establecido para dicha cola, si se cumplió se lo intenta mover a una cola de menor prioridad (de existir) y se marca como READY.
|
|
|
Al haber un _unblock_ se intenta "premiar" a la tarea (que no utilizó completamente su quantum antes de ser desalojada), moviéndola a una cola de mayor prioridad.
|
|
|
|
|
|
-
|
|
|
-
|
|
|
-
|
|
|
-
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
+
|
|
|
|
|
|
|
|
|
|
|
|
@@ -31,8 +35,9 @@ Al haber un _unblock_ se intenta "premiar" a la tarea (que no utilizó completam
|
|
|
Se puede observar que este scheduler es *muy* ineficiente para casos en los que se utiliza mucho CPU y poco IO; todas las tareas quedan en la cola de menor prioridad y sucede lo mismo que vimos en el scheduler RR: la relación quantum / context switch es muy mala.
|
|
|
|
|
|
Observación: Este scheduler debería ser 'bueno' para tareas interactivas pero esto no se da ya que al tener una implementación ingenua sin `CPU Pinning` perdemos mucho tiempo cuando las tareas cambian de core.
|
|
|
-Definiciones
|
|
|
-====
|
|
|
+
|
|
|
+\newpage
|
|
|
+# Definiciones
|
|
|
|
|
|
* Latencia: Cantidad de ticks en ready hasta que se ejecuta la primera task. Esta métrica se puede extender para ver la latencia promedio de todos los procesos que corrió el scheduler.
|
|
|
* Waiting time: Cantidad de ticks en ready durante toda la ejecución de un proceso.
|
