Cambio de contexto de subproceso vs. cambio de contexto de proceso

¿Alguien podría decirme qué se hace exactamente en ambas situaciones? ¿Cuál es el costo principal de cada uno de ellos?

La principal distinción entre un conmutador de subproceso y un conmutador de proceso es que durante un conmutador de subproceso, el espacio de memoria virtual permanece igual, mientras que no lo hace durante un cambio de proceso. Ambos tipos implican entregar el control al núcleo del sistema operativo para realizar el cambio de contexto. El proceso de cambiar dentro y fuera del núcleo del sistema operativo junto con el costo de cambiar los registros es el mayor costo fijo de realizar un cambio de contexto.

Un costo más difuso es que un cambio de contexto interfiere con los mecanismos de almacenamiento en caché de los procesadores. Básicamente, cuando cambia de contexto, todas las direcciones de memoria que el procesador "recuerda" en su caché se vuelven efectivamente inútiles. La única gran distinción aquí es que cuando cambia los espacios de memoria virtual, el búfer de traducción Lookaside (TLB) del procesador o equivalente se vacía, lo que hace que los accesos a la memoria sean mucho más caros durante un tiempo. Esto no sucede durante un cambio de hilo.

El cambio de contexto de proceso implica cambiar el espacio de direcciones de memoria. Esto incluye direcciones de memoria, asignaciones, tablas de páginas y recursos del núcleo, una operación relativamente costosa. En algunas arquitecturas, incluso significa vaciar varios cachés de procesador que no se pueden compartir en los espacios de direcciones. Por ejemplo, x86 tiene que vaciar el TLB y algunos procesadores ARM tienen que vaciar todo el caché L1.

El cambio de subproceso es el cambio de contexto de un subproceso a otro en el mismo proceso (el cambio de subproceso a subproceso a través de los procesos es solo el cambio de proceso). Cambiar el estado del procesador (como el contador del programa y el contenido del registro) generalmente es muy eficiente.

En primer lugar, el sistema operativo pone el hilo saliente en modo kernel si aún no está allí, porque el cambio de hilo solo se puede realizar entre hilos, que se ejecuta en modo kernel. Luego se invoca el planificador para tomar una decisión sobre el hilo al que se realizará el cambio. Después de tomar una decisión, el núcleo guarda parte del contexto del hilo que se encuentra en la CPU (registros de la CPU) en el lugar dedicado en la memoria (con frecuencia en la parte superior de la pila del núcleo del hilo saliente). Luego, el kernel realiza el cambio de la pila de kernel del subproceso saliente a la pila de kernel del subproceso entrante. Después de eso, el núcleo carga el contexto previamente almacenado del hilo entrante de la memoria en los registros de la CPU. Y finalmente regresa el control al modo de usuario, pero en modo de usuario del nuevo hilo. En el caso de que el sistema operativo haya determinado que el hilo entrante se ejecuta enotro proceso, el kernel realiza un paso adicional: establece un nuevo espacio de dirección virtual activo.

El costo principal en ambos escenarios está relacionado con una contaminación de caché. En la mayoría de los casos, el conjunto de trabajo utilizado por el subproceso saliente diferirá significativamente del conjunto de trabajo utilizado por el subproceso entrante. Como resultado, el hilo entrante comenzará su vida con una avalancha de errores de caché, eliminando así los datos antiguos e inútiles de los cachés y cargando los nuevos datos de la memoria. Lo mismo es cierto para TLB (Traducción Look Aside Buffer, que está en la CPU). En el caso del restablecimiento del espacio de direcciones virtuales (los subprocesos se ejecutan en diferentes procesos), la penalización es aún peor, porque el restablecimiento del espacio de direcciones virtuales conduce al vaciado de todo el TLB, inclusosi el nuevo hilo realmente necesita cargar solo unas pocas entradas nuevas. Como resultado, el nuevo hilo comenzará su tiempo cuántico con muchos errores de TLB y frecuentes recorridos de página. El costo directo del cambio de subprocesos tampoco es despreciable (desde ~ 250 y hasta ~ 1500-2000 ciclos) y depende de la complejidad de la CPU, los estados de ambos subprocesos y los conjuntos de registros que realmente utilizan.

PD: Buena publicación sobre gastos generales de cambio de contexto: http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html

• cambio de proceso: es una transición entre dos memorias residentes del proceso en un entorno de multiprogramación;
• cambio de contexto: es un contexto cambiante de un programa en ejecución a una rutina de servicio de interrupción (ISR).

En Thread Context Switching, el espacio de memoria virtual permanece igual mientras que no es en el caso de Process Context Switch. Además, el cambio de contexto de proceso es más costoso que el cambio de contexto de subproceso.

Creo que la principal diferencia es cuando se llama, switch_mm()que maneja los descriptores de memoria de tareas viejas y nuevas. En el caso de los subprocesos, el espacio de direcciones de la memoria virtual no cambia (los subprocesos comparten memoria virtual), por lo que debe hacerse muy poco y, por lo tanto, es menos costoso.

Si bien el cambio de contexto de subproceso necesita cambiar el contexto de ejecución (registros, punteros de pila, contadores de programa), no necesitan cambiar el espacio de direcciones como lo hacen los cambios de contexto de procesos. Hay un costo adicional cuando cambia el espacio de direcciones, más acceso a la memoria (paginación, segmentación, etc.) y tiene que vaciar TLB al ingresar o salir de un nuevo proceso ...

En resumen, el cambio de contexto de subproceso no asigna un nuevo conjunto de memoria y pid, usa lo mismo que el padre ya que se ejecuta dentro del mismo proceso. Un proceso genera un nuevo proceso y, por lo tanto, asigna nuevos mem y pid.

Hay muchísimo más que eso. Han escrito libros sobre eso.

En cuanto al costo, un hilo de cambio de contexto de proceso >>>> ya que debe restablecer todos los contadores de pila, etc.

Suponiendo que la CPU que ejecuta el sistema operativo tiene algunos dispositivos de alta latencia conectados,

Tiene sentido ejecutar otro subproceso del espacio de direcciones del proceso, mientras el dispositivo de alta latencia responde.

Pero, si el dispositivo de alta latencia responde más rápido que el tiempo necesario para configurar la tabla + traducción de memorias virtuales a físicas para un proceso NUEVO, entonces es cuestionable si un cambio es esencial.

Además, la caché HOT (los datos necesarios para ejecutar el proceso / subproceso son accesibles en menos tiempo) es una mejor opción.