usuario - Estados de proceso de Linux
ver procesos de un usuario linux (8)
Asumiendo que su proceso es un hilo único, y que está usando E / S de bloqueo, su proceso bloqueará la espera de que se complete la E / S. Mientras tanto, el kernel escogerá otro proceso para ejecutar basado en la bondad, la prioridad, el último tiempo de ejecución, etc. Si no hay otros procesos ejecutables, el kernel no ejecutará ninguno; en su lugar, indicará al hardware que la máquina está inactiva (lo que dará como resultado un menor consumo de energía).
Los procesos que están esperando a que se complete la E / S normalmente aparecen en el estado D en, por ejemplo, ps y top .
En Linux, ¿qué ocurre con el estado de un proceso cuando necesita leer bloques de un disco? Está bloqueado? Si es así, ¿cómo se elige ejecutar otro proceso?
Como ya explicaron otros, los procesos en el estado "D" (suspensión ininterrumpida) son responsables de la suspensión del proceso ps. Para mí, esto ha sucedido muchas veces con RedHat 6.x y directorios home de NFS automáticos.
Para enumerar procesos en estado D puede usar los siguientes comandos:
cd /proc
for i in [0-9]*;do echo -n "$i :";cat $i/status |grep ^State;done|grep D
Para conocer el directorio actual del proceso y, puede ser, el disco NFS montado que tiene problemas, puede usar un comando similar al del siguiente ejemplo (reemplace 31134 con el número del proceso de suspensión):
# ls -l /proc/31134/cwd
lrwxrwxrwx 1 pippo users 0 Aug 2 16:25 /proc/31134/cwd -> /auto/pippo
Descubrí que dando el comando umount con el modificador -f (force), al sistema de archivos nfs montado relacionado, era capaz de reactivar el proceso de suspensión:
umount -f /auto/pippo
el sistema de archivos no fue desmontado, porque estaba ocupado, pero el proceso relacionado se activó y pude resolver el problema sin reiniciar.
Cuando un proceso necesita recuperar datos de un disco, deja de ejecutarse de manera efectiva en la CPU para permitir que se ejecuten otros procesos porque la operación puede demorar mucho tiempo en completarse: al menos 5 ms de tiempo de búsqueda para un disco es común, y 5 ms es 10 millones Ciclos de CPU, una eternidad desde el punto de vista del programa!
Desde el punto de vista del programador (también se dice "en el espacio de usuario"), esto se llama una llamada al sistema de bloqueo . Si llama a write(2) (que es un contenedor libc delgado alrededor de la llamada del sistema del mismo nombre), su proceso no se detiene exactamente en ese límite: continúa, en el lado del kernel, ejecutando el código de llamada del sistema. La mayoría de las veces llega hasta un controlador de controlador de disco específico (nombre de archivo → sistema de archivos / VFS → dispositivo de bloque → controlador de dispositivo), donde un comando para recuperar un bloque en el disco se envía al hardware adecuado: esta es una muy operación rápida la mayor parte del tiempo.
ENTONCES el proceso se pone en estado de reposo (en el espacio del kernel, el bloqueo se denomina dormir; nada está ''bloqueado'' desde el punto de vista del kernel). Se despertará nuevamente una vez que el hardware finalmente haya obtenido los datos correctos, luego el proceso se marcará como ejecutable , programado y ejecutado tan pronto como el planificador lo permita.
Finalmente, en el espacio de usuario, la llamada del sistema de bloqueo regresa con el estado y los datos correctos, y el flujo del programa continúa.
Es posible invocar la mayoría de las llamadas al sistema de E / S en modo no bloqueante (vea O_NONBLOCK en open(2) y fcntl(2) ). En este caso, el sistema llama de inmediato y solo informa sobre el envío correcto de la operación del disco. El programador tendrá que verificar explícitamente en un momento posterior si la operación se completó, con éxito o no, y obtendrá su resultado (por ejemplo, con select(2) ). Esto se llama programación asincrónica o basada en eventos.
La mayoría de las respuestas aquí que mencionan el estado D (cuyo nombre exacto es TASK_UNINTERRUPTIBLE de nombres de TASK_UNINTERRUPTIBLE de Linux) son incorrectas. El estado D es un modo de suspensión especial que solo se activa en una ruta de código de espacio de kernel, cuando esa ruta de código no se puede interrumpir (porque sería complejo de programar), la mayoría de las veces con la esperanza de que bloquearía muy corto. Creo que la mayoría de los "estados D" son realmente invisibles, tienen una vida muy corta y no se pueden observar con herramientas de muestreo como ''top''.
Pero a veces encontrará esos procesos imposibles de resolver en estado D en algunas situaciones. NFS es famoso por eso, y lo he encontrado muchas veces. Creo que hay un choque semántico entre algunas rutas de códigos VFS que suponen que siempre llegan a los discos locales y detección rápida de errores (en SATA, un tiempo de espera de error sería de unos 100 ms), y NFS que realmente obtiene datos de la red que es más resistente y tiene una recuperación lenta (es común un tiempo de espera TCP de 300 segundos). Lea este artículo para la solución genial presentada en Linux 2.6.25 con el estado TASK_KILLABLE . Antes de esta era había un truco en el que podías enviar señales a los clientes del proceso NFS enviando un SIGKILL al hilo del núcleo rpciod , pero olvídate de ese truco feo ...
En general, el proceso se bloqueará. Si la operación de lectura está en un descriptor de archivo marcado como no bloqueante o si el proceso está utilizando IO asíncrono, no se bloqueará. Además, si el proceso tiene otros hilos que no están bloqueados, pueden continuar ejecutándose.
La decisión sobre qué proceso se ejecuta a continuación depende del scheduler en el kernel.
Sí, la tarea se bloquea en la llamada al sistema read (). Otra tarea que está lista se ejecuta, o si no hay otras tareas listas, se ejecuta la tarea inactiva (para esa CPU).
Una lectura de disco de bloqueo normal hace que la tarea entre en el estado "D" (como otros han notado). Estas tareas contribuyen al promedio de carga, a pesar de que no consumen la CPU.
Algunos otros tipos de IO, especialmente ttys y red, no se comportan de la misma manera: el proceso termina en estado "S" y puede interrumpirse y no cuenta en contra del promedio de carga.
Sí, las tareas que esperan IO están bloqueadas y se ejecutan otras tareas. La selección de la siguiente tarea la realiza el planificador de Linux .
Un proceso que realiza E / S se colocará en estado D (suspensión ininterrumpible) , lo que liberará la CPU hasta que haya una interrupción de hardware que le indique a la CPU que vuelva a ejecutar el programa. Ver man ps para los otros estados del proceso.
Dependiendo de su kernel, hay un planificador de procesos , que realiza un seguimiento de una secuencia de procesos listos para ejecutarse. Esto, junto con un algoritmo de programación, le dice al núcleo qué proceso asignar a qué CPU. Hay procesos kernel y procesos de usuario a considerar. A cada proceso se le asigna un segmento de tiempo, que es un fragmento de tiempo de CPU que puede usar. Una vez que el proceso utiliza todo su segmento de tiempo, se marca como caducado y se le da menor prioridad en el algoritmo de programación.
En el kernel 2.6 , hay un programador de complejidad de tiempo O (1) , así que no importa cuántos procesos tenga en ejecución, asignará CPU en tiempo constante. Sin embargo, es más complicado, ya que 2.6 preemption y el balanceo de carga de la CPU no es un algoritmo fácil. En cualquier caso, es eficiente y las CPU no permanecerán inactivas mientras espera la E / S.
Mientras se espera que read() o write() llegue a / desde un archivo descriptor return, el proceso pasará a un tipo especial de suspensión, conocido como "D" o "Disk Sleep". Esto es especial, porque el proceso no se puede matar ni interrumpir mientras se encuentre en ese estado. Un proceso que espera un retorno de ioctl () también se pondrá a dormir de esta manera.
Una excepción a esto es cuando un archivo (como un terminal u otro dispositivo de caracteres) se abre en modo O_NONBLOCK , se pasa cuando se supone que un dispositivo (como un módem) necesitará tiempo para inicializarse. Sin embargo, indicó dispositivos de bloque en su pregunta. Además, nunca he probado un ioctl() que pueda bloquearse en un fd abierto en modo no bloqueo (al menos no a sabiendas).
La forma en que se elija otro proceso depende por completo del planificador que esté utilizando, así como de lo que otros procesos hayan podido hacer para modificar sus ponderaciones dentro de ese programador.
Se sabe que algunos programas de espacio de usuario en ciertas circunstancias permanecen en este estado para siempre, hasta que se reinician. Estos se agrupan típicamente con otros "zombies", pero el término no sería correcto ya que técnicamente no están extintos.