El es la decisión del kernel sobre thread listo recibe la CPU , y durante . Como normalmente hay más threads ejecutables que cores, el los multiplexa, buscando equilibrar objetivos en conflicto — , y — a la vez que evita la (inanición).
El es la decisión del kernel sobre thread listo recibe la CPU , y durante . Como normalmente hay más threads ejecutables que cores, el los multiplexa, buscando equilibrar objetivos en conflicto — , y — a la vez que evita la (inanición).
FCFS (first-come, first-served) → simple, pero un job largo bloquea a todos (convoy effect)
SJF (shortest job first) → espera media óptima, pero hay que conocer la duración; puede matar de hambre a los largos
Round-robin (RR) → a cada job un TIME SLICE fijo (quantum), rotando → justo, buena latencia
Priority → primero la prioridad más alta → puede MATAR DE HAMBRE a la baja prioridad (arreglo: aging)
MLFQ (multi-level feedback) → varias colas de prioridad; los jobs que usan un quantum completo bajan,
los jobs interactivos que ceden se quedan arriba → aproxima SJF sin conocer duraciones
Round-robin ilustra la perilla central — el quantum:
quantum too SMALL → justo y responsivo, pero mucho overhead de context-switch
quantum too LARGE → menos overhead, pero degrada hacia FCFS (mala responsividad)
El valor por defecto de Linux durante mucho tiempo fue CFS (Completely Fair Scheduler): en lugar de porciones fijas, rastrea el virtual runtime (vruntime) de cada tarea y siempre ejecuta el thread que ha recibido menos CPU hasta el momento, ponderado por su valor nice — aproximando "todos reciben una parte justa". Indexa un red-black tree por vruntime, de modo que elegir la siguiente tarea es O(log n). (Los kernels más nuevos usan EEVDF, un refinamiento con el mismo objetivo de equidad más límites de latencia más ajustados.)
Preemptive vs cooperative: los OS modernos son preemptive — una timer interrupt permite al scheduler recuperar la CPU por la fuerza, de modo que un thread no puede monopolizar un core.
El scheduling moldea directamente la latencia y el throughput que perciben los usuarios. Los entrevistadores lo exploran para ver si entiendes los compromisos — por qué una carga de trabajo interactiva quiere quanta cortos o un impulso de prioridad, por qué el priority scheduling necesita aging para prevenir la starvation, y cómo MLFQ/CFS logran un buen comportamiento interactivo sin conocer de antemano la duración de los jobs. Es también el modelo mental detrás de ajustar nice, las prioridades de tiempo real, y diagnosticar un servicio hambriento (starved) o con lag.
Una biblioteca de preguntas de entrevista de IT con respuestas detalladas — de Junior a Senior.
Donar