Scheduling

Ricardo Corin

Introduccin

Mltiples procesos en estado READY compiten por tiempo de CPUs

Si | Ready| > |CPU|, no podemos ejecutar todos simultneamente

El planificador o scheduler se ocupa de seleccionar cules procesos se van a ejecutar

El scheduler usa algn algoritmo de planificacin para esto

Un buen scheduler es fundamental!

Introduccin

En los sistemas tipo Batch antiguos el algoritmo de scheduling era simple: hay una cola FIFO de procesos de llegada, y se va eligiendo el prximo proceso a medida que va terminando el actual En sistemas de tiempo compartido (time-sharing) se complic porque haba que atender a muchos usuarios a la vez Con las primeras PC, no era tan grave el scheduling porque generalmente haba un solo proceso principal ejecutndose

Introduccin

El problema de eficiencia de scheduling se:

Agrava con el advenimiento de sistemas operativos con interfaces grficas complicadas y conectividad (por ejemplo, servidores brindando mltiples servicios) Reduce con el advenimiento de hardware ms rpido, y mltiple CPUs Pero se agrava de nuevo en dispositivos mviles con energa restringida (bateras que duran poco)

Introduccin

An as elegir cul proceso ejecutar puede ser crucial. Supongamos que hay un proceso que quiere actualizar la pantalla, y otro que quiere enviar un mail. Cul conviene elegir primero?

Introduccin

Context-switching es caro, por lo que cada decisin hecha por el scheduler es costosa:

Cambiar de modo usuario a modo kernel Guardar el estado del proceso (registros, mapa de memoria) que est siendo interrumpido en la PCB Elegir nuevo proceso Cargar el estado del nuevo proceso Lanzar el nuevo proceso, saliendo del modo kernel Adems, el CS borra el cache de memoria; y la memoria asignada a procesos puede haber cambiado

Introduccin

Los procesos son CPU-bound o I/O bound

Cpu bound: mucha computacin, poco IO IO bound: viceversa Como afecta esto al scheduling?

Introduccin

Los procesos se vuelven cada vez ms IO bound

Los CPUs progresan mas rpido que los HD y red Si tenemos que elegir entre un proceso IO bound y uno CPU bound, conviene elegir primero al IO bound!

Cuando planificar ( scheduliar)

Cuando hay algn cambio en el estado de un proceso

Evento Creacin Finalizacin Bloqueo Cambio en PCB Agrega al Ready Quita del Running De Running a Blocked Decisin de scheduling Quin elegir?, padre o hijo? Quin elegir de Ready? idem

Interrupcin que De Blocked a Ready Seguir con el desbloquea un actual? Cambiar? proceso

Preemptive or not

Adems de las acciones anteriores, el scheduler puede invocarse en:

Cada cierto tiempo, el scheduler se invoca y potencialmente desaloja al proceso que se est ejecutando (scheduler preemptivo o apropiativo)

Necesitamos si o si usar interrupciones de reloj

Un proceso simplemente decide no ejecutarse ms (pasa de running a ready). El scheduler tiene que elegir otro proceso, y se dice que es no-apropiativo

Esto puede ser peligroso! while(1);

Tipos de planificadores

Diferentes tipos dependiendo de la situacin:

Batch: schedulers no apropiativos o apropiativos de perodos largos (an se usan por ej. en bancos) Interactive: si o si apropiativo! Queremos bajo tiempo de respuesta Realtime: aplicaciones que necesitan predictabilidad y control de metas. A veces no hace falta que el scheduler sea apropiativo si los procesos saben que tienen que ejecutarse rpido Mviles? Celulares, tablets...

no podemos tener muchos procesos...

Objetivos de schedulers

Todos:

Fairness (equidad): dar a todos los procesos una porcin de CPU Cumplimiento de polticas: por ejemplo, si se desea que cada usuario no tenga ms de n procesos o 30seg de CPU por minuto Balance: mantener todos los componentes del sistema ocupado

Idealmente, tener un mix de CPU y I/O bound

Objetivos de schedulers

Batch:

Throughput: maximizar la cantidad de trabajos completados por unidad de tiempo Turn-around-time: minimizar el tiempo entre el comienzo del trabajo y la finalizacin

Se toma el promedio entre todos los procs

Utilizacin de CPU: mantener el CPU utilizado todo el tiempo

Objetivos de schedulers

Interactivos:

Tiempo de respuesta: responder rpidamente a los pedidos de usuarios y con poca varianza Proporcionalidad: cumplir con los tiempos que el usuario espera

Es psicolgico! Cerrar una ventana debera ser rpido Conectarse a internet no tanto

Objetivos de schedulers

Tiempo real:

Cumplir con los plazos

Por ejemplo, un proceso que samplea datos de una fuente externa cada n msec, debera ser despertado apropiadamente Mantener cierta estabilidad de ejecucin sin grandes variaciones Por ejemplo, en una aplicacin de streaming de audio se puede perder algn plazo, pero si se ejecuta muy errticamente la calidad del sonido se deteriorar

Predictabilidad

Planificacin en sistemas Batch

Asumimos 1 CPU, misma prioridad entre todos los procesos Los procesos:

Llegan en un momento dado (variable Arribo) Se empiezan a ejecutar despus (variable Inicio) Terminan en un momento dado (variable Fin) Usan el CPU un tiempo dado (variable TiempoUso) TurnAround = T = Fin - Arribo TiempoEspera = M = T TiempoUso

Planificacin en sistemas Batch

FCFS: first come, first serve

Bsicamente una cola donde los procesos van llegando y siendo atendidos en el orden de llegada

Como en un banco o en el supermercado

Sencillo y fcil de implementar, menor sobrecarga pero muy ineficiente Es no-apropiativo (no preemptivo)

Ejemplo FCFS
Proceso A B C D Media Arribo 0 1 2 3 TiempoUso 3 100 1 100 Inicio 0 3 103 104 Fin 3 103 104 204 T 3 102 102 201 102 M 0 2 101 101 51

Es bueno para los largos (por ejemplo B) pero muy malo para los cortos (por ejemplo C) Se refleja en el M y T grandes La tabla se puede diagramar tambin

SJF shortest job first

Si podemos saber o predecir el tiempo de uso de antemano, podemos planificar primero los procesos ms cortos

Cun realista es esto? Por ej., para procesos conocidos como ser liquidar sueldos
Arribo 0 0 0 0 TiempoUso 3 100 1 100 Inicio 1 4 0 104 Fin 4 104 1 204 T 4 104 1 204 53,25 M 1 4 0 104 27,25

Proceso A B C D Media

SJF shortest job first

De hecho este scheduler es ptimo Ejemplo: con FCFS, (a) de abajo da un T de

(8 + (8+4) + (8+4+4) + (8+4+4+4) ) / 4 = 14

Con SJF:

(4 + (4+4) + (4+4+4) + (4+4+4+8) ) / 4 = 11

En gral: (4A + 3B + 2C + D) /4

SJF

(4A + 3B + 2C + D) /4

Es ptimo si los procesos estn ordenados

Funciona cuando los procesos llegan simultneamente, y podemos predecir los tiempos de uso Es no-apropiativo

SRTN shortest remaining time next

Versin apropiativa del SJF: cuando llega un proceso, evaluamos si conviene interrumpir o no, de acuerdo a si el tiempo de uso del proceso recin llegado es menor a lo que resta de ejecutar al proceso actual Peor turnaround que SJF y mas Context switches
Proceso A B C D Media Arribo 1 0 2 3 TiempoUso 3 100 1 100 Inicio 1 0 2 105 Fin 6 105 3 205 T 5 105 1 202 78,25 M 2 5 0 102 27,25

Scheduling en sistemas interactivos

Round robin RR

Es como el FCFS pero apropiativo por tiempo Simple, bueno, y justo

Round robin

Cada proceso tiene un quanto de tiempo (=5 en ej.), si no termina antes se interrumpe y se pasa al siguiente; el proceso interrumpido se encola al final
Arribo 0 1 2 3 TiempoUso 3 100 1 100 Inicio 0 3 8 9 Fin 3 199 9 204 T 3 198 7 201 102,25 M 0 98 6 101 51,25 A B C D

Proceso

Media

Round robin

No necesita saber el tiempo de uso! Tenemos que intentar minimizar la cantidad de context switches

Quanto chico: sobrecarga de CS Quanto grande: poca respuesta en procesos interactivos

El caso extremo degenera en FCFS

Se usan quantos de 20-50msec en la prctica

Scheduling de prioridad

Usamos mltiples colas de acuerdo a la prioridad de cada proceso

Scheduling de prioridad

La prioridad se puede asignar en forma manual

Comando nice en linux

O dinmicamente por el sistema de acuerdo a si son I/O o CPU bound

Procesos IO bound pasan mas tiempo bloqueados que los CPU bound Cul conviene que tenga mas lta prioridad si queremos minimizar el nmero de context switches?

Scheduling de prioridad

CPU bound > baja prioridad, IO bound alta prioridad A medida que los procesos usan o no todo su quanto lo voy acomodando en la cola de prioridad Si usan todo el quanto quiere decir que son mas CPU bound, lo bajo de prioridad Si usan menos, lo subo porque es mas IO bound

Scheduling de prioridad

Podemos usar RR en cada prioridad, y ejecutar empezando por la prioridad ms alta hasta que se terminen todos los procesos, luego pasar a la inmediata inferior y hacer lo mismo

Cada prioridad mas baja tiene el quanto del doble de tiempo que la inmediata superior Problemas?

Mltiples colas

Los procesos en colas bajas se pueden morir de inanicin! Esquema alternativo llamado mltiples colas:

Tomo el primer proceso de la cola de ms alta prioridad Si se le acaba el quanto, lo bajamos de prioridad Ejemplo: proceso que usa 100 quantos: empieza en la prioridad mas alta, 1 quanto. Despues 2, 4, 8, 16, 32, y 64 (usa slo 37). Usamos solamente 7 context switches!

Scheduling de prioridad

Problema: no hay promocin de prioridades, los procesos se hunden cada vez ms abajo Idea: cuando un proceso se vuelve interactivo le queremos subir la prioridad

Por ej. cuando en una terminal pulsan Enter Cuando pasa cierto tiempo esperando por IO

Shortest process next

Queremos estimar el tiempo de uso para usar algo parecido a SJF en sistemas interactivos Mido el tiempo t0 que toma en ejecutarse la primera vez; despus mido la segunda vez en t1 La estimacin siguiente es t = a.t1 + (1-a)t0 En gral, tn+1 = a.tn + (1-a)tn-1

Si a es chico, favorecemos la memoria, si es grande favorecemos el cambio Caso a=1/2 es razonable y eficiente de implementar

Fair-Share y Guaranteed scheduling

Fair-share

Hasta consideramos procesos sin tener en cuenta a que usuario pertenecen Usando RR es fcil que un usuario se aproveche del CPU: larga muchos procesos y listo

Guaranteed

Asegurar 1/n porcin de CPU si hay n usuarios Necesitamos ir llevando la cuenta del consumo Util por ej. cuando uno compra una porcin de mquina virtual (VPS: virtual private system)

Lottery scheduling
Lottery

A cada proceso se le dan nmeros de lotera por los recursos del sistema (CPU, memoria,...) El sistema hace una lotera peridicamente (por ej. 50 veces por segundo) El que gana en cada se le da el recurso por 20msec A procesos con ms prioridad les damos ms tickets, incrementando las posibilidades de ganar Los tickets son intercambiables!

Por ej. un cliente le da tickets a un servidor bloqueado

Scheduling de threads

Aunque los threads de nivel de usuario son eficientes, no permiten que el SO los eschedulee (a), mientras que los de kernel si se pueden (b)

Scheduling en Linux

Round-robin con prioridad ajustada dinmicamente

Procesos de mucho tiempo son penalizados en prioridad Procesos a los que no se le dio CPU en mucho tiempo son promocionados en prioridad

Permite ajustar la prioridad programaticamente!

Soporta procesos ejecutandose en realtime

Se aplica a Linux 2.2-2.4

http://oreilly.com/catalog/linuxkernel/chapter/ch10.html

Scheduling en Linux

Scheduling en Linux

El tiempo de CPU se divide en pocas

En cada poca se calcula el quanto de cada proceso (pueden ser diferentes!) Los procesos se ejecutan hasta que se les acaba el quanto a todos, entonces termina la poca Como se tienen procesos escheduliados en modo realtime y otros no, linux define una funcion goodness() que elige el mejor proceso a seleccionar

Scheduling en Linux

Qu pasa en el caso multicore? Si un proceso fue ejecutado en un CPU en particular, se intenta que siga en ese CPU para aprovechar caches Pero qu pasa por ej. si tenemos que un CPU se liber y podemos migrar un proceso desde otro CPU que est ocupado?

Linux tiene un esquema emprico, dependiendo del tamao del cache del CPU (PROC_CHANGE_PENALTY)

Scheduling en Linux

Funciona bien con algunas decenas de procesos Pero con muchos no anda tan bien

Es costoso recomputar las prioridades dinmicas Si no se recomputan lo suficientemente rpido, los procesos de IO bound no suben en prioridad, y esto afecta la performance

Nuevos schedulers

2.6 2.6.28: O(1) scheduler

Bsicamente esquema RR con mltiples colas de prioridad Eleccin en tiempo constante

2.6.28--- presente: CFS completely fair scheduler

Se mantiene un rbol ordenado con los tiempos de uso de CPU de cada proceso Se elige siempre al proceso que ha esperado ms tiempo (p->wait_runtime)

Experimentos con el scheduler de linux 2.6.38

Vamos a experimentar corriendo varias tareas de larga duracin Necesitamos algn proceso que tarde mucho! (CPU bound, no IO bound!)

Sleep(100) sirve?

Dgitos de PI
Pi = 4* arctan(1)

benchmarks
30

25

20

15

digitos

10

0 500

1500

2500

3500

4500

Time

Real: el tiempo que pas, de ppio a fin

Incluye tiempo bloqueado y de otros procesos

User: el tiempo que us el proceso

Sin contar otros usuarios ni tiempo bloqueado

Sys: el tiempo que el proceso esper a llamadas al sistema

Osea ejecucin en modo kernel dedicado al proceso

Guarda con el redondeo! (en el ej., sys+user > real)

Ejecucin en paralelo

Porqu tardaron lo mismo?

Porque es una mquina multi-core!

cat /proc/cpuinfo

Haciendo htop:

CPU: quinto parmetro empezando del final en archivo /proc/<pid>/stat

Ejecutemos en el mismo CPU!

taskset -c CPU_NR ./pi.sh 3000

Corre el comando ./pi.sh 3000 en el CPU CPU_NR

Linux Trace Toolkit (lttng.org)

Herramienta de logueo del sistema Funciona como un demonio especial que graba todas las acciones del sistema Entorno grfico de exploracin!

lttv-gui

lttv

Procesos con sus PID (0 = kernel), birth time

Resolucin en ns!

Colores:

azul: corriendo en kernel Verde: en CPU rojo: esperando IO Amarillo oscuro: READY (esperando CPU) Verde oscuro: esperando por fork (syscall)

Corriendo 2 ejecuciones

Tenemos concurrencia!

Sh /usr/bin/bc fork

Ahora ejecutamos en el mismo CPU

Linux realtime chrt

Podemos correr en tiempo real un proceso chrt -r 99 ./pi.sh 3000

Congela la mquina!

Sin chrt: