Malte Skarupke un desarrollador de juegos publico una comparación del rendimiento de los bloqueos basados ​​en Mutex y Spinlock utilizando varios programadores de tareas. Las pruebas mostraron retrasos anormalmente largos al usar Spinlock con el programador de tareas predeterminado en Linux.

El autor de las pruebas concluyó que el programador de tareas de Linux tiene problemas que afectan negativamente el trabajo de los juegos creados para el servicio Google Stadia, en los que los juegos se ejecutan en la GPU en un entorno en la nube y el cliente solo transmite contenidos de pantalla de hasta 60 cuadros en segundo.

En tales condiciones, es necesario garantizar la visualización oportuna de los cuadros en la pantalla y se notan retrasos superiores a un milisegundo.

Linus Torvalds se unió a la discusión de las pruebas, quien las llamó “basura pura” y un ejemplo de cómo obtener indicadores que no reflejen la realidad real sin comprender completamente el tema.

Torvalds escribió:

Toda la publicación parece estar equivocada y está midiendo algo completamente diferente de lo que el autor piensa y afirma que está midiendo”.

En primer lugar, los spinlocks solo se pueden usar si realmente sabes que no estás programado mientras los usas … Básicamente lee la hora antes de liberar el bloqueo, y luego lo lee después de volver a adquirir el bloqueo, y afirma que es la hora la diferencia es el momento en que no se mantuvo el bloqueo. Lo cual es estúpido e inútil y completamente incorrecto.

Eso es pura basura “.

Spinlock es una primitiva de bajo nivel que debe usarse en el espacio del usuario con gran cuidado y comprender completamente los detalles; de lo contrario, puede obtener lo que demostró el autor de la prueba.

Linus aconsejó a los desarrolladores de juegos que no usen spinlock y que no intenten bloquear sus propios sistemas de bloqueo basados ​​en él, sino que usen mecanismos probados existentes que informen al sistema sobre la espera de que se libere el bloqueo para eliminar la influencia del programador.

Los complementos basados ​​en Spinlock se pueden usar solo con plena confianza de que el programador no interrumpirá su ejecución. Los bloqueos basados ​​en spinlock utilizados en las pruebas se implementan a través de un enlace casero que funciona en el espacio del usuario.

El programador de tareas puede tomar el control en cualquier momento durante la ejecución de este enlace y cambiar a otra tarea.

Dado que la medición del rendimiento se basa en valores absolutos del temporizador, los retrasos definidos en las pruebas cubren no solo los retrasos en el controlador de bloqueo, sino también el código que se ejecutó en un contexto diferente, es decir.

No solo mide lo que el autor de la prueba intentó medir, sino también el “ruido” de otros cálculos en el sistema.

El problema es que los desarrolladores no deberían haber estado usando spinlocks en primer lugar, por lo que en lo que respecta, no fue el culpable el programador de Linux, sino los enfoques de los desarrolladores para usarlo.

El autor de la prueba intentó objetar a Linus, señalando que el uso de sistemas de bloqueo basados ​​en spinlock patentados a menudo se usa en la práctica en los juegos, ya que cuando se usan programadores más simples que en Linux, las pruebas muestran un mejor rendimiento.

Linus menciono que el planificador de Linux es universal, refinado durante décadas y optimizado no solo para el escritorio y los juegos, sino también para otros tipos de cargas de trabajo, por ejemplo, sistemas de servidor y por lo tanto tiene en cuenta muchos matices al planificar las tareas.

Agregar optimizaciones específicas que reducirán la latencia en los juegos de Google Stadia puede aumentar la capacidad de respuesta en un caso particular, pero es probable que reduzca el rendimiento general del programador.

Por ejemplo, el Programador de Windows se comporta mejor en las pruebas en discusión, ya que es mucho más simple que el Programador de Linux y está optimizado principalmente para tareas específicas del escritorio.

Fuente: https://probablydance.com/