En mi programa tengo varios hilos que se inician con el proceso y que permanecen hasta que finaliza el programa. Se enfrentarán a diferentes cargas durante la vida útil de la aplicación y, en ocasiones, todas funcionarán al 100%.
De forma predeterminada, el programador de subprocesos de Linux cambiará la afinidad en un sistema multinúcleo para estos subprocesos de manera bastante frívola en mi opinión. Cuando miro los gráficos de rebote en mi monitor de proceso gráfico (el de gnome) no puedo evitar pensar que esto constituye algún tipo de sobrecarga.
EDITAR:Para aclarar, incluso para cargas muy estables, los subprocesos se programan en diferentes núcleos y, aunque no es visible en la imagen proporcionada, a veces queda muy claro que el núcleo seleccionado para cada subproceso se "intercambia" con frecuencia.
¿Este cambio constante de afinidad no afectará negativamente al rendimiento?
En ese caso, ¿por qué se implementa de esta manera? ¿Qué beneficios tiene la afinidad cambiante?
Mis conjeturas son:
- Nivelación de desgaste: no ponga todo el trabajo en un solo núcleo
- Involuntario: algún algoritmo inteligente intenta optimizar el uso dependiendo de la carga y sucede que la sobrecarga no es lo suficientemente significativa como para justificar mantener la afinidad en lugar de cambiarla.
Respuesta1
Si va a ejecutar todos los subprocesos en un núcleo, compre hardware más barato con un solo núcleo.
El planificador intenta aprovechar al máximo todos los núcleos. Esto significa enviar subprocesos a cualquier núcleo que tenga algo de tiempo libre. Mover un hilo de un núcleo a otro tiene un costo pequeño, por lo que el programador intenta evitarlo. Pero normalmente no lo notarás mucho, porque el beneficio de no dejar que un núcleo quede inactivo es mucho mayor que el costo de migrar un subproceso. Esto es especialmente cierto si los subprocesos usan más memoria que la que tiene la memoria caché local del núcleo: si la memoria utilizada por un subproceso no está en la caché local del núcleo, hay muy poco que perder al migrarla a otro núcleo.
Dudar de un programador de nivel industrial como el de Linux generalmente empeora el rendimiento.
Los gráficos que muestra indican que la carga en los distintos núcleos no es completa y ligeramente variable, presumiblemente porque su sistema en su conjunto está limitado por la E/S para las tareas que está realizando en este momento, no por la potencia de la CPU. No dice nada en un sentido u otro en cuanto a la frecuencia con la que los subprocesos se mueven de un núcleo a otro.
Respuesta2
La instantánea proporcionada aquí también depende del tipo (versión) del kernel. Los núcleos más antiguos con la versión 2.4 tenían poca afinidad, lo que provocaba un gran movimiento de subprocesos que afectaba al rendimiento del sistema. Las versiones del kernel a partir de la 2.5 tienen una afinidad relativamente mejor.
En un sistema basado en múltiples núcleos, la configuración de la afinidad puede mejorar el rendimiento, al evitar que se produzca la invalidación de la caché al mover un subproceso entre los núcleos.
En el caso de un sistema multinúcleo basado en Linux, el comportamiento de afinidad del programador (afinidad natural) se puede anular según el tipo de aplicación/requisito mediante el uso de sched_setaffinity/taskset para el proceso y pthread_setaffinity_np para el subproceso.
tiburón núcleoparece proporcionar una mejor representación visual del sistema multinúcleo y la afinidad.
Además, tenga en cuenta quearribaproporcionar soporte visual para establecer la afinidad (para anular el programador).