|
|
@@ -30,22 +30,32 @@ Las tareas consisten en los siguientes 3 casos:
|
|
|
* __IO Heavy:__ Tareas con poco consumo de CPU (comparadas a _CPU Heavy_) pero con un alto uso de IO.
|
|
|
* __Interacción de usuario:__ Consiste en varios procesos con uso de IO seguidos de procesos con alto uso de CPU. Para simular la entrada de un usuario y el procesamiento de programas o scripts del mismo.
|
|
|
|
|
|
+### Descripción del algoritmo
|
|
|
+
|
|
|
+En el lote de tareas provisto se puede observar que este scheduler alcanza un buen balance entre throughput y waiting time.
|
|
|
+Este algoritmo prioriza tareas cortas y tareas con mucho IO, la idea es intentar "premiar" a las tareas que pasan mucho tiempo bloqueadas, haciendolas esperar la menor cantidad de tiempo posible.
|
|
|
+A las tareas más largas o con mucho uso de CPU este algoritmo les reduce la prioridad pero les asigna mas quantums, ¿¿¿lo que mejora su throughput????.
|
|
|
+
|
|
|
+Las tareas priorizadas usan el CPU poco tiempo, por lo que es bueno reducir el tiempo que pasan esperando, para dar respuesta rápida.
|
|
|
+Las otras tareas requieren más recursos, por lo que no les afecta tanto esperar un poco más si eso significa obtener mas quantum.
|
|
|
+
|
|
|
### Uso elevado de CPU
|
|
|
|
|
|
|
|
|
+En este caso se puede ver claramente la priorización de tareas con IO (3,4,5) sobre las tareas que consumen todo su quantum y son asignadas a una cola de menor prioridad.
|
|
|
|
|
|
### Uso elevado de IO
|
|
|
|
|
|
+En este caso se puede ver que la priorización de procesos "interactivos" consume completamente el CPU (hasta ~160), donde finalmente pueden ejecutar los procesos que estaban en la segunda cola.
|
|
|
+
|
|
|
+\newpage
|
|
|
|
|
|
### Interacción de usuario
|
|
|
|
|
|
|
|
|
+En este caso podemos ver un buen lote de tareas para el scheduler; las tareas "interactivas" tienen bajo waiting time mientras que las tareas con uso intensivo de CPU tienen mayor waiting time pero también reciben mas quantum.
|
|
|
|
|
|
-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.
|
