so-tp1/informe/9-informe.md

\newpage

Ejercicio 9

Para la implementación de este ejercicio utilizando:

Map<pid, process> En dicho Map se almacena un descriptor struct con datos del proceso actual como: pid, state y quantum_count, a los que se accede utilizando el pid como clave.

vector<queue<pid>> En este vector se almacenan las distintas colas de ejecución, en las mismas se almacena solo el pid para poder luego consultarlo en el mapa si es necesario accederlo.

vector<uint> Este vector tiene el mismo tamaño que el vector utilizado anteriormente y se utiliza para almacenar el cuantum correspondiente al índice de cada cola. Por ejemplo la cola en la posición 0 del arreglo de colas tiene el quantum almacenado en la posición 0 de este arreglo.

Esto nos permite poder mantener cada cola de prioridad con los PIDs que tiene asignados e ir pasandolos de cola en cola sin tener que migrar todos los datos del proceso, ya que al mismo se accede por su PID mientras se encuentre en ejecución.

En el constructor del scheduler se lee la cantidad de parámetros, con esto se inicializan los dos vectores (con las colas y los quantums) y se almacena el quantum correspondiente a cada cola segun el orden en el que se reciben. (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 (La cola en la posición 0). 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 (número más alto) 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.

Casos de prueba

Para probar el funcionamiento del scheduler, se procedió a mandar fruta en las tareas que encontramos más comunes en la vida real.

Las tareas consisten en los siguientes 3 casos:

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.

\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.
• Tiempo total de ejecución / Turn around time: Intervalo de ticks desde que se ejecuta un proceso hasta su terminación. No incluye latencia.
• Throughput : Numero de procesos completado por el sistema por unidad de tiempo.