TEMA 2. GESTIÓN DE PROCESOS - Universidad de Almería

Diseño de Sistemas Operativos
Tema 2. Gestión de Procesos
• Los procesos de tipo SCHED_OTHER únicamente pueden ejecutarse cuando no existe ningún
proceso de “tiempo real” en estado de listo para ejecutarse. El proceso a ejecutar se escoge tras
examinar las prioridades dinámicas. La prioridad dinámica de un proceso se basa por una parte en
el nivel especificado por el usuario según las llamadas al sistema nice y setpriority, y por otra parte
en una variación calculada por el sistema. Todo proceso que se ejecute durante varios ciclos de
reloj disminuye en prioridad y puede así llegar a ser menos prioritario que los procesos que no se
ejecutan, cuya prioridad no se ha modificado.
Existen numerosas llamadas al sistema que permiten modificar la política y los parámetros asociados a un
proceso, entre ellas destacamos las siguientes:
• int sched_setscheduler(pid_t pid, int policy, const struct sched_param *param). Modifica la
política (policy) y los parámetros de planificación (param) asociados al proceso (pid).
• int sched_getscheduler(pid_t pid). Obtiene la política (SCHED_FIFO, SCHED_RR o
SCHED_OTHER) de planificación asociada al proceso (pid) o al proceso actual si pid = 0.
• int sched_setparam(pid_t pid, const struct sched_param *param) y int sched_getparam(pid_t pid,
struct sched_param *param). Establece y obtiene los parámetros de planificación asociados al
proceso (pid).
• int sched_get_priority_min(int policy) y int sched_get_priority_max(int policy). Obtiene
prioridades minima y máxima asociadas a la política de planificación (policy).
• int sched_rr_get_interval(pid_t pid, struct timespec *interval). Devuelve en la estructura “interval”
el quantum de tiempo asociado al proceso (pid) que debe ser del tipo SCHED_RR.
• int sched_yield(void). Permite al proceso actual liberar al procesador. Al ejecutar esta primitiva, el
proceso actual se coloca al final de la lista de procesos “listos para ejecutarse en memoria” y
entonces se ejecuta el scheduler. Si no existen otros procesos en el sistema, cambia al proceso
actual.
La planificación de procesos (scheduler) la implementa la función schedule situada en el archivo fuente
kernel/sched.c. También es preciso mencionar a la función goodness que devuelve un valor que indica a
schedule hasta qué punto el proceso necesita el procesador. Por ello goodness, puede devolver: –1000 si se
trata del proceso actual para indicar que no debe seleccionarse; prioridad estática + 1000 si es un proceso
tiempo real; número de ciclos de reloj que el proceso debe ejecutarse (counter) si se trata de un proceso
normal.
La función schedule que implementa la planificación de procesos, empieza por desplazar el proceso actual al
final de los procesos listos (llamando a move_last_runqueue) si el proceso ha agotado todos sus ciclos (su
tiempo). Si el proceso esta en estado = TASK_INTERRUPTIBLE, entonces schedule comprueba si ha
recibido una señal; si es así estado = TASK_RUNNING con el objetivo de despertarlo. Para ello, schedule
explora todos los procesos de la Tabla de Procesos, llama a la función goodness para escoger el siguiente
proceso a ejecutar y al volver de la búsqueda, el proceso escogido se convierte en el proceso actual.
Entonces, get_mmu_context llama para restaurar el contexto de memoria del proceso y switch_to se llama
para provocar el cambio de contexto.
La función schedule gestiona el tiempo asociado a cada proceso a través del campo counter del descriptor del
proceso, pudiendo reiniciarlo cuando considere oportuno. El campo counter determina el número de ciclos
de reloj durante los cuales el proceso debe ejecutarse. El campo counter puede ser modificado por:
• update_process_time. Esta función es llamada periódicamente por timer_bh, que forma parte de la
cola de tareas tq_timer, activada por el manejador de interrupciones del reloj. Poniendo la variable
need_rsched a 1 si el proceso ha agotado su quantum.
• add_to_runqueue. Esta función añade un proceso a la lista de procesos “listos para ejecutarse en
memoria”.
Departamento de Lenguajes y Computación. Universidad de Almería Página 2.65