ej 9

casos/consola.tsk

@@ -0,0 +1,7 @@
+*3 TaskConsola 5 1 4
+@5:
+*4 TaskConsola 4 1 3
+@6:
+*5 TaskConsola 5 1 2
+@8:
+TaskConsola 1 7 10

casos/mfq_4c_gral.json

@@ -1,8 +1,9 @@
 { "title": "Multiples casos, 4 core, CS: 2",
   "filename": "informe/imagenes/caso_mfq_4_gral.png",
   "list" : [
-	{ "tasks": "casos/cpu.tsk",     "args": "4 2 9 SchedMFQ 6 2" },
-	{ "tasks": "casos/cpuh_io.tsk", "args": "4 2 9 SchedMFQ 6 2" },
-	{ "tasks": "casos/cpu_ioh.tsk",     "args": "4 2 9 SchedMFQ 6 2" }
+	{ "tasks": "casos/cpu.tsk",			"args": "4 2 9 SchedMFQ 6 2" },
+	{ "tasks": "casos/cpuh_io.tsk",		"args": "4 2 9 SchedMFQ 6 2" },
+	{ "tasks": "casos/cpu_ioh.tsk",     "args": "4 2 9 SchedMFQ 6 2" },
+	{ "tasks": "casos/consola.tsk",     "args": "4 2 9 SchedMFQ 6 2" }
   ]
 }

informe/9-informe.md

@@ -5,7 +5,7 @@ Implementamos este ejercicio utilizando:
  * `Map<pid, process>`
  * `vector<queue<pid>>`
 
-Donde quantum y pid son `unsigned int`.
+Donde pid es `unsigned int`.
 
 Esto nos permite:
 
@@ -17,12 +17,20 @@ En dicho `Map` se almacena un `struct` con datos del proceso actual como: _pid_,
 En el constructor se leen los parámetros que recibe la cantidad de ticks a asignar por quantum a cada cola (esto le da la 'prioridad' a cada cola).
 
 Cada vez que se carga un nuevo proceso, el mismo se aloja en la cola de mayor prioridad.
-Al haber un _tick_ se controla que no se haya cumplido el _quantum_ establecido para dicho nucleo, si se cumplió se lo intenta mover a una cola de menor prioridad y se marca como READY.
+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.
 
-![Lotes: CPU | CPU Heavy + IO | CPU esporadico + Heavy IO](informe/imagenes/caso_mfq_4_gral.png)
+![](informe/imagenes/ejercicio9_gantt_casos_1.png)
+![](informe/imagenes/ejercicio9_gantt_casos_2.png)
+![](informe/imagenes/ejercicio9_gantt_casos_3.png)
+![](informe/imagenes/ejercicio9_gantt_casos_4.png)
 
+![Lotes: CPU | CPU Heavy + IO | CPU esporadico + Heavy IO | Interactivo](informe/imagenes/caso_mfq_4_gral.png)
 
+
+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
 ====