usuario - Costo de cambio de contexto entre hilos del mismo proceso, en Linux

ver procesos corriendo en linux

Question

¿Hay algún dato empírico bueno sobre el costo del cambio de contexto entre subprocesos del mismo proceso en Linux (x86 y x86_64, principalmente, son de interés)? Estoy hablando de la cantidad de ciclos o nanosegundos entre la última instrucción que un subproceso ejecuta en el espacio de usuario antes de que se ponga en suspensión voluntaria o involuntariamente, y la primera instrucción se ejecuta un subproceso diferente del mismo proceso después de despertarse en la misma CPU / núcleo .

Escribí un programa de prueba rápida que realiza constantemente rdtsc en 2 subprocesos asignados a la misma cpu / core, almacena el resultado en una variable volátil y se compara con la variable volátil correspondiente de su subproceso hermano. La primera vez que detecta un cambio en el valor del subproceso hermano, imprime la diferencia y luego vuelve al bucle. De esta manera, obtengo un conteo mínimo / mediano de aproximadamente 8900/9600 ciclos en una CPU Atom D510. ¿Este procedimiento parece razonable y los números parecen creíbles?

Mi objetivo es estimar si, en los sistemas modernos, el modelo de servidor de subproceso por conexión podría ser competitivo o incluso superar al multiplexado de tipo selecto. Esto parece plausible en teoría, ya que la transición de realizar IO en fd X a fd Y implica simplemente irse a dormir en un hilo y despertarse en otro, en lugar de múltiples llamadas, pero depende de la sobrecarga del cambio de contexto.

Answer 1

(Descargo de responsabilidad: Esta no es una respuesta directa a la pregunta, solo son algunas sugerencias que espero sean útiles).

En primer lugar, los números que obtienes sonar como si estuvieran dentro del campo de juego. Sin embargo, tenga en cuenta que la latencia de interrupción / captura puede variar mucho entre los diferentes modelos de CPU que implementan la misma ISA. También es una historia diferente si sus subprocesos han usado operaciones de punto flotante o vector, porque si no lo han hecho, el kernel evita guardar / restaurar el estado de punto flotante o unidad vectorial.

Debería poder obtener números más precisos mediante el uso de la infraestructura de rastreo del kernel; en particular, el programa de planificación está diseñado para medir y analizar la latencia del programador.

Si su objetivo es modelar servidores de subprocesos por conexión, entonces probablemente no debería medir la latencia involuntaria del cambio de contexto; por lo general, en ese servidor, la mayoría de los cambios de contexto serán voluntarios, como bloques de un hilo en read() espera. Para más datos de la red. Por lo tanto, un mejor banco de pruebas puede implicar medir la latencia de un bloqueo de subproceso en un read() a otro que se despierta desde el mismo.

Tenga en cuenta que en un servidor de multiplexación bien escrito con gran carga, la transición de fd X a fd Y a menudo implicará la misma llamada al sistema (ya que el servidor se repite en una lista de descriptores de archivos activos devueltos desde una sola epoll() ). Un subproceso también debería tener menos espacio de almacenamiento en caché que varios subprocesos, simplemente por tener solo una pila. Sospecho que la única forma de resolver el asunto (para una definición de "liquidación") podría ser tener un tiroteo de referencia ...