06 - planificacion y gestion de procesos

Upload: luisdajo

Post on 06-Jul-2015

38 views

Category:

Documents


0 download

TRANSCRIPT

Ampliacin de Sistemas OperativosTema 6: Planificacin y Gestin de Procesos

Introduccin Abordaremos tres aspectos de la gestin de procesos Estructuras de datos relacionadas con gestin de procesos El algoritmo de planificacin y el cdigo del planificador El cambio de contexto

(c) 2004 J. Ignacio Garca Tejedor

Planificacin y Gestin de Procesos - 2

Estructuras de datos (I) Descriptor de proceso Informacin sobre lo que un proceso est haciendo

Prioridad Estado (ejecutndose, bloqueado, etc.) Espacio de direcciones asignado Ficheros abiertos PID Etc.

Representado por una estructura task_struct Correspondencia de un descriptor por cada proceso

Sin embargo, como veremos, algunas partes pueden compartirse entre procesos La direccin del descriptor de proceso (32 bits) es un buen identificador del proceso en sPlanificacin y Gestin de Procesos - 3

(c) 2004 J. Ignacio Garca Tejedor

Estructuras de datos (II) PID Identificador de proceso (Process ID) Forma tradicional de identificar procesos en UNIX Los nmeros de PID se asignan secuencialmente Aunque es un entero de 32 bits, slo se usan nmeros hasta el 32767 por compatibilidad

Si se supera este nmero, el kernel tiene que reciclar PIDs

Debe existir una forma rpida de derivar el puntero al descriptor del proceso en base al PID

Array de tareas Linux mantiene un array de tamao NR_TASKS de punteros a task_struct Nmero de procesos limitado, aunque ms adecuado que en versiones anteriores(c) 2004 J. Ignacio Garca Tejedor Planificacin y Gestin de Procesos - 4

Estructuras de datos (III) Almacenamiento de los descriptores de proceso Asignacin dinmica (aunque con una cach) Linux almacena dos estructuras de datos para el mismo proceso en un nica a rea de 8Kb

El descriptor de proceso La pila de modo kernel del procesounion task_union { struct task_struct task; unsigned long stack[2048]; };Pila

La macro current La circunstancia anterior permite obtener un puntero el descriptor del proceso actual en base a ESP, con lo que se mejora la eficiencia Esta tarea la realiza la macro current, que se utiliza con profusin, truncando los 13 LSB de ESP

current

Descriptor de Proceso

Ejemplo: current->pidPlanificacin y Gestin de Procesos - 5

(c) 2004 J. Ignacio Garca Tejedor

Estructuras de datos (IV) La lista de procesos Para realizar bsquedas eficientes, el kernel crea varias listas de procesos, como ya vimos en temas anteriores Existe una lista circular doblemente enlazada denominada la lista de procesos Se usan los campos prev_task y next_task de task_struct para crear la lista La cabeza de la lista siempre es el descriptor de init_task; el proceso 0 o swapper Las macros SET_LINKS y REMOVE_LINKS insertan y extraen procesos de la lista teniendo en cuenta sus relaciones de parentesco La macro for_each_task recorre toda la lista y se usa para realizar acciones repetitivas sobre la misma.#define for_each_task(p) \ for (p=&init_task ; (p = p->next_task) != &init_task ; )

(c) 2004 J. Ignacio Garca Tejedor

Planificacin y Gestin de Procesos - 6

Estructuras de datos (V) Lista de procesos TASK_RUNNING Sera muy ineficiente buscar el siguiente proceso a ejecutar en toda la lista Por ello existe una lista circular doblemente enlazada de procesos listos para ejecutar (runqueue) Los descriptores tienen los campos next_run y prev_run para implementar la lista, con init_task como cabecera. La variable nr_running indica el nmero total de procesos. Para manejar la lista existen funciones como add_to_runqueue(), del_from_runqueue(), u otras relacionadas como wake_up_process()(c) 2004 J. Ignacio Garca Tejedor Planificacin y Gestin de Procesos - 7

Estructuras de datos (VI) La tabla pidhash (I) En ocasiones es necesario encontrar rpidamente un descriptor en base al PID

Por ejemplo, en una llamada a kill()

Se mantiene una tabla donde almacenar correspondencias entre PID y puntero a descriptor de tamao PIDHASH_SZ (generalmente NR_TASKS/4)

NR_TASKS en general suele ser 512

El PID se transforma en un ndice en la tabla mediante una funcin hash, con la macro pid_hashfn(x)#define pif_hashfn(x) \ ((((x) >> 8) ^ (x)) & (PIDHASH_SZ 1))(c) 2004 J. Ignacio Garca Tejedor Planificacin y Gestin de Procesos - 8

Estructuras de datos (VII) La tabla pidhash (II) Lgicamente, dos PIDs pueden dar el mismo ndice en la tabla (colisin), por lo que en cada entrada de la tabla ser una lista de descriptores de los PID que colisionan

pidhash

Esta lista se implementa con los campos pidhash_next y pidhash_prev del descriptor de proceso

100

PID 228 PID 27536

PID 27535

123

Para manejar la tabla hay funciones como hash_pid(), unhash_pid() o find_task_by_pid()

(c) 2004 J. Ignacio Garca Tejedor

Planificacin y Gestin de Procesos - 9

Estructuras de datos (VIII) Relaciones de parentesco El kernel mantiene las relaciones de parentesco entre procesos mediante punteros a descriptor

p_optr (original parent) Padre del proceso o 1 (init) si el padre ha muerto p_pptr (parent) Igual que el anterior aunque a veces puede diferir cuando se depura un proceso p_cptr (child) Hijo ms joven del proceso p_ystr (younger sibling) Proceso creado inmediatamente despus por el mismo padre p_ostr (older sibling) Proceso creado inmediatamente antes por el mismo padre

De esta forma un proceso padre puede obtener todos sus procesos hijos(c) 2004 J. Ignacio Garca Tejedor Planificacin y Gestin de Procesos - 10

Descriptor de proceso (I) Se describen a continuacin otros campos de task_struct volatile long state; Estado del proceso.

TASK_RUNNING: Ejecutandose o esperando su turno para ejecutarso TASK INTERRUPTIBLE: Suspendido hasta que una condicin se cumpla TASK_UNINTERRUPTIBLE: Igual al anterior, pero si recibe una seal se mantiene en el mismo estado TASK_STOPPED: Proceso parado tras recibir una seal de parada SIGSTOP, SIGSTP, SIGINT o SIGTTOU TASK_ZOMBIE: Ejecucin finalizada pero el padre no ha efectuado aun un wait()

unsigned long flags; Flags de estado a nivel de kernel(c) 2004 J. Ignacio Garca Tejedor Planificacin y Gestin de Procesos - 11

Descriptor de proceso (II) long counter; Nmero de ticks para que se le termine el quantum al proceso long priority; Prioridad esttica del proceso struct task_struct *next_run, *prev_run; Descritos con anterioridad int exit_code, exit_signal; Cdigo de salida del proceso o numero de seal si muri por una seal int pid; Identificador de proceso struct task_struct *p_opptr, *p_pptr, *p_cptr, *p_ysptr, *p_osptr; Descritos anteriormente unsigned long policy, rt_priority; Poltica de planificacin long start_time; Momento de creacin del proceso uid_t uid,euid,suid,fsuid; Usuario propietario del proceso gid_t gid,egid,sgid,fsgid; Grupo propietario del proceso unsigned long signal, blocked; Mapa de bits con las seales enviadas al proceso y las bloqueadas(c) 2004 J. Ignacio Garca Tejedor Planificacin y Gestin de Procesos - 12

Descriptor de proceso (III) El descriptor contiene otros campos que son punteros a otras estructuras Generalmente denotan recursos del sistema Son punteros por dos motivos:

Son dinmicos, no de tamao fijo Facilita la comparticin de recursos entre procesos (p.e. threads) struct fs_struct *fs; Asociado con el directorio actual struct files_struct *files; Asociado a los ficheros abiertos del proceso struct mm_struct *mm; Asociado con descriptores de regiones de memoria struct signal_struct *sig; Seales recibidas struct tty_struct *tty; Terminal asociado con el procesoPlanificacin y Gestin de Procesos - 13

Los campos son:

(c) 2004 J. Ignacio Garca Tejedor

Planificacin (I) Sistema de tiempo compartido Se obtiene la ilusin de varios procesos ejecutndose simultneamente En realidad se conmutan los procesos cada poco tiempo El algoritmo de planificacin es el encargado de determinar cundo y cmo seleccionar un nuevo proceso a ejecutar. A esto se le denomina poltica de planificacin

La poltica de planificacin debeTener un tiempo de respuesta rpido Buen rendimiento para procesos en background Evitar la inanicin de procesos Tener en cuenta las necesidades de los procesos de alta y baja prioridad Etc (c) 2004 J. Ignacio Garca Tejedor Planificacin y Gestin de Procesos - 14

Planificacin (II) Caractersticas: El tiempo de CPU se divide en trozos o slices, uno para cada proceso ejecutable. Est basado en interrupciones del timer Es necesario un sistema de clasificacin de procesos basado en sus prioridades

En Linux, la prioridad es dinmica. El scheduler ajusta las prioridades peridicamente

Tipos de procesos Tradicionalmente, dos tipos de procesos: Intensivos en E/S e Intensivos en CPU Alternativamente podramos distinguir

Procesos interactivos. Requieren tiempos de respuesta pequeos Procesos por lotes (Batch). No requieren interaccin con el usuario Procesos de tiempo real. Requisitos de planificacin muy fuertes y tiempo de respuesta corto y poco variablePlanificacin y Gestin de Procesos - 15

Linux tiende a favorecer los procesos intensivos en E/S

(c) 2004 J. Ignacio Garca Tejedor

Planificacin (III) Expulsin de procesos (process preemption) Un proceso puede ceder la CPU voluntariamente, pero tambin puede serle requisada Si un proceso pasa a estado TASK_RUNNING, el kernel comprueba si su prioridad es mayor que la de current, en cuyo caso se llama al planificador para que seleccione otro proceso

Por ejemplo, cuando un proceso que estaba esperando una interrupcin de teclado, la recibe y pasa a estado activo

Tambin puede expulsarse un proceso porque termina su quantum de tiempo

En este caso se pone el campo need_resched a 1, para que se invoque el planificador al terminar el ISR del timer

Un proceso al que se le requisa la CPU NO est suspendido, puesto que permanece en estado TASK_RUNNING EL kernel de Linux no es expulsivo; slo se realiza expulsin cuando un proceso se ejecuta en modo usuario.

Linux no es, por tanto, adecuado para Tiempo RealPlanificacin y Gestin de Procesos - 16

(c) 2004 J. Ignacio Garca Tejedor

Planificacin en Linux (I) Funcionamiento general Linux divide el tiempo de CPU en pocas (epoch) En cada epoch, cada proceso tiene un quantum de tiempo que se asigna al comenzar el epoch Cuando un proceso agota su quantum, se le expulsa y se selecciona otro proceso ejecutable Un proceso puede ser seleccionado mltiples veces, mientras no agote su quantum

Por ejemplo, puede haber sido expulsado tras una E/S, propia o ajena

La poca termina cuando todos los procesos ejecutables han agotado su quantum

En este momento, se reasignan los quantum para la siguiente poca. Linux favorece los procesos que no han agotado su quantum en la poca anteriorPlanificacin y Gestin de Procesos - 17

(c) 2004 J. Ignacio Garca Tejedor

Planificacin en Linux (II) Quantum de tiempo en Linux Todos los procesos tienen un quantum base, que es el que se asigna al comenzar el epoch si en el anterior el proceso agot todo su quantum

Suele tomar como valor DEF_PRIORITY, aunque puede variarse mediante nice() o setpriority()#define DEF_PRIORITY (20*HZ/100)

Al quantum base se le aade un bonus por no agotar el quantum en el epoch anterior igual a la mitad de los ticks que le quedaran por consumir

Por lo tanto, el quantum nunca ser mayor que dos veces la prioridad base

Cada vez que se produce una interrupcin del timer, se resta 1 al quantum restante del proceso actual Cuando un proceso hace un fork(), el quantum que le resta se reparte entre el proceso y el proceso hijo(c) 2004 J. Ignacio Garca Tejedor Planificacin y Gestin de Procesos - 18

Planificacin en Linux (III) Prioridad Para seleccionar qu proceso ejecutar, el planificador toma en cuenta la prioridad de un proceso

Esttica: asignada a procesos de tiempo real (1-99) Dinmica: asignada a procesos convencionales. Es funcin de la prioridad base y de los ticks del quantum restantes en la poca actual

La prioridad esttica siempre es superior a la dinmica, por lo que slo se ejecutan procesos convencionales cuando no quedan procesos de tiempo real por ejecutar

(c) 2004 J. Ignacio Garca Tejedor

Planificacin y Gestin de Procesos - 19

Implementacin de la Planificacin en Linux (I) Se emplean varios campos del descriptor de proceso need_resched: Este flag indica si es necesario invocar a schedule() tras una operacin como una interrupcin, una llamada al sistema, etc policy: Clase de planificacin del proceso

SCHED_FIFO: Proceso en TR First-in first-out. El proceso ocupa la CPU hasta que quiera, aunque haya otros procesos de TR con la misma prioridad. SCHED_RR: Proceso en TR Round Robin. Cuando el scheduler le asigna la CPU lo pone al final de la runqueue de forma que todos los procesos de igual prioridad y clase tengan las mismas oportunidades SCHED_OTHER: Proceso convencional de tiempo compartido SCHED_YIELD: Este bit se activa para ceder la CPU voluntariamente durante el prximo ciclo de planificacin

rt_priority: Prioridad esttica de un proceso RT priority: Prioridad base (o quantum base) del proceso counter: Ticks de CPU restantes del proceso en el epoch actual(c) 2004 J. Ignacio Garca Tejedor Planificacin y Gestin de Procesos - 20

Implementacin de la Planificacin en Linux (II) Seleccin de un proceso goodness() es la funcin que evala en qu medida es apropiado (good) un proceso para ser seleccionado segn su valor de vuelta

c = -1000: El proceso no debe seleccionarse (init_task) c = 0: El proceso ha agotado su quantum 0policy != SCHED_OTHER) return 1000 + p->rt_priority; if(p->counter == 0) return 0; if( p->mm == prev-mm) return p->counter + p->priority + 1; return p->counter + p->priority;

(c) 2004 J. Ignacio Garca Tejedor

Planificacin y Gestin de Procesos - 21

Implementacin de la Planificacin en Linux (III) Invocacin de schedule() La funcin schedule() es la que implementa el planificador Cundo se invoca a schedule()?

De forma directa. (p.e. tras bloquearse en una cola de espera) De forma indirecta (lazy invocation). Estableciendo need_resched a 1. Dado que el valor de este flag se chequea siempre antes de volver a modo usuario, eventualmente se invocar schedule() en un futuro cercanoPlanificacin y Gestin de Procesos - 22

(c) 2004 J. Ignacio Garca Tejedor

Implementacin de la Planificacin en Linux (IV) La funcin schedule() (I) Es una funcin de aspecto poco ortodoxo para ser C, puesto que emplea muchos saltos con goto y etiquetas

La idea es que el camino de ejecucin ms frecuente no tenga ningn salto y sea ms rpido Los cuerpos de los if se sustituyen por un salto y una etiqueta de vueltaif (tq_scheduler) goto handle_tq_scheduler; tq_scheduler_back: ... handle_tq_scheduler: run_task_queue(&tq_scheduler); goto tq_scheduler_back;

Se definen dos punteros bsicos, prev y next y una variable c

prev apunta al proceso que se estaba ejecutando en la CPU El objetivo es que next apunte al proceso que va a ejecutarse c se emplea para almacenar la prioridad mxima encontradaPlanificacin y Gestin de Procesos - 23

(c) 2004 J. Ignacio Garca Tejedor

Implementacin de la Planificacin en Linux (V) La funcin schedule() (II) Si hay tareas en la cola tq_scheduler, se ejecutan Si hemos llegado aqu en medio de una interrupcin, algo grave ha ocurrido Si hay bottom halves pendientes, se ejecutan Si estabamos ejecutando un proceso SCHED_RR y este ha agotado su quantum, se le asigna otro y se coloca al final de la runqueue Si la tarea actual est suspendida y no ha recibido seales que pueda atender, se saca de la runqueue Se pone need_resched a 0 A continuacin, se selecciona qu proceso ser el prximo que se ejecutar.(c) 2004 J. Ignacio Garca Tejedor Planificacin y Gestin de Procesos - 24

Implementacin de la Planificacin en Linux (VI) La funcin schedule() (III) Se recorre la runqueue, empezando por el primer proceso, que ser init_task->next_run El proceso next por defecto es init_task, y c es -1000

Si el proceso actual tiene estado TASK_RUNNING, se le favorece en la eleccin por motivos de eficiencia (Nos ahorramos un cambio de contexto) Si el proceso actual tiene activado SCHED_YIELD, su peso es 0

Se recorre la lista obteniendo el peso (godness) de cada proceso

Si al final del proceso c es igual a cero, se ha acabado el epoch y recalculamos los quantum de cada proceso, reiniciando la planificacin Tenemos en next el proceso al que conmutar. Salvo que sea el mismo en que estabamos, realizamos la conmutacin llamando a switch_to()(c) 2004 J. Ignacio Garca Tejedor Planificacin y Gestin de Procesos - 25

Consideraciones de rendimiento El planificador de Linux no es perfecto Es sencillo y es fcil modificar ciertos parmetros al gusto, pero no es adecuado para todos los entornos

Algunos de sus problemas: El algoritmo no escala bien. Cuando el nmero de procesos es grande, se tarda mucho en recalcular las prioridades dinmicas y los quantums, y los procesos intensivos en E/S no ganan casi prioridad con el tiempo (pocas muy largas) El quantum predefinido es demasiado grande para sistemas con mucha carga o de gran rendimiento. La responsividad depende mucho de la carga del sistema. El algoritmo de dar preferencia a los procesos intensivos en E/S no es ptimo. No distingue si un proceso es interactivo o no. El soporte para aplicaciones de Tiempo Real es muy pobre. Esto es causado por ser el kernel no preemptive.(c) 2004 J. Ignacio Garca Tejedor Planificacin y Gestin de Procesos - 26

Linux 2.4 UIDs y GIDs de 32 bits Se elimina el array tasks, por lo que no hay lmite preestablecido de procesos Mejoras en el refresco de las TLBs. El directorio global de pginas lo establece schedule(), en lugar de switch_to() Mejoras en los algoritmos de planificacin para sistemas SMP

(c) 2004 J. Ignacio Garca Tejedor

Planificacin y Gestin de Procesos - 27