¿Fijar un proceso a un núcleo de CPU o un nodo SMP ayuda a reducir el tráfico de coherencia de caché?

Question

Es posible fijar un proceso a un conjunto específico de núcleos de CPU utilizando la llamada sched_setaffinity(). La página de manual dice:

Restricting a process to run on a single CPU also avoids the 
    performance cost caused by the cache invalidation that occurs when a process 
    ceases to execute on one CPU and then recommences execution on a different 
    CPU. 

Que es casi una cosa obvia (¿o no?). Lo que no es tan obvio para mí es esto -

¿Fijar los LWP a una CPU específica o un nodo SMP reduce el tráfico del bus de coherencia de caché? Por ejemplo, dado que un proceso se está ejecutando, otras CPU no deberían modificar su memoria privada, por lo tanto, solo las CPU que son parte del mismo nodo SMP deberían permanecer coherentes.

Answer 1

No debe haber tráfico de coherencia de socket a socket de CPU para el caso de proceso fijado que usted describe. Las plataformas Xeon modernas implementan el filtrado de snoop en el chipset. El filtro snoop indica cuando un socket remoto no puede tener la línea de caché en cuestión, evitando así la necesidad de enviar caché invalidando mensajes a ese socket.

Puede medir esto usted mismo. Los procesadores Xeon implementan una gran variedad de contadores de estadísticas de caché. Puede leer los contadores en su propio código con la instrucción rdpmc o simplemente usar un producto como VTune. Para su información, usar rdpmc es muy preciso, pero un poco complicado ya que inicialmente tiene que establecer un bit en CR4 para permitir el uso de esta instrucción en el modo de usuario.

- EDITAR -

Mi respuesta anterior no está actualizado para la serie 55xx de CPUs que utilizan enlaces QPI. Estas tomas de enlaces de interconexión de la CPU directamente sin un chipset intervenir, como en: http://ark.intel.com/products/37111/Intel-Xeon-Processor-X5570-%288M-Cache-2_93-GHz-6_40-GTs-Intel-QPI%29

Sin embargo, desde la memoria caché L3 en cada CPU es inclusivo, fisgones a través de los enlaces QPI sólo se producen cuando la caché local L3 indica que la línea está en ninguna parte el enchufe local. Del mismo modo, el L3 del zócalo remoto puede responder rápidamente a un cross-snoop sin molestar a los núcleos, suponiendo que la línea no está allí tampoco.

Por lo tanto, las cachés L3 inclusivas deben minimizar la sobrecarga de coherencia entre sockets, simplemente no es debido a un filtro snoop de chipset en su caso.

Answer 2

Si se ejecuta en un sistema NUMA (como, servidor Opteron o Itanium), tiene sentido, pero hay que estar seguro de vincular un proceso al mismo nodo NUMA que asigna memoria. De lo contrario, esto es una anti-optimización. Cabe señalar que cualquier sistema operativo compatible con NUMA intentará mantener la ejecución y la memoria en el mismo nodo de todos modos, si no le dice nada en absoluto, en la medida de sus capacidades (algunas versiones antiguas de Windows son bastante pobres en esto, pero no esperaría que ese fuera el caso con Linux reciente).

Si no se ejecuta en un sistema NUMA, enlazar un proceso a un núcleo en particular es la mayor estupidez que puede hacer. El OS no hará hacer rebotar los procesos entre CPU por diversión, y si un proceso debe ser movido a otra CPU, entonces eso no es ideal, pero el mundo tampoco termina. Ocurre con poca frecuencia, y cuando lo hace, difícilmente podrá decirlo.
Por otro lado, si el proceso está vinculado a una CPU y otra CPU está inactiva, el sistema operativo no puede usarla ... es decir, el 100% de la potencia de procesamiento disponible se ha ido por el desagüe.