Malt Skarupke un desenvolupador de jocs public una comparació de el rendiment dels bloquejos basats en Mutex i spinlock utilitzant diversos programadors de tasques. Les proves van mostrar retards anormalment llargs a l'usar spinlock amb el programador de tasques per defecte en Linux.
L'autor de les proves va concloure que el programador de tasques de Linux té problemes que afecten negativament el treball de els jocs creats per al servei Google Stadia, en els que els jocs s'executen a la GPU en un entorn en el núvol i el client només transmet continguts de pantalla de fins a 60 quadres en segon.
En aquestes condicions, cal garantir la visualització oportuna dels quadres a la pantalla i es noten retards superiors a un mil·lisegon.
Linus Torvalds es va unir a la discussió de les proves, qui les va anomenar «escombraries pura» i un exemple de com obtenir indicadors que no reflecteixin la realitat real sense comprendre completament el tema.
Torvalds va escriure:
Tota la publicació sembla estar equivocada i està mesurant una cosa completament diferent del que l'autor pensa i afirma que està mesurant ».
En primer lloc, els spinlocks només es poden usar si realment saps que no estàs programat mentre els fas servir ... Bàsicament llegeix l'hora abans d'alliberar el bloqueig, i després ho llegeix després de tornar a adquirir el bloqueig, i afirma que és l'hora la diferència és el moment en què no es va mantenir el bloqueig. La qual cosa és estúpid i inútil i completament incorrecte.
Això és pura escombraries «.
Spinlock és una primitiva de baix nivell que s'ha d'utilitzar en l'espai de l'usuari amb gran cura i comprendre completament els detalls; en cas contrari, pot obtenir el que va demostrar l'autor de la prova.
Linus va aconsellar als desenvolupadors de jocs que no usin spinlock i que no intentin bloquejar els seus propis sistemes de bloqueig basats en ell, sinó que usin mecanismes provats existents que informin el sistema sobre l'espera que s'alliberi el bloqueig per eliminar la influència de programador.
Els complements basats en spinlock es poden usar només amb plena confiança que el programador no interromprà la seva execució. Els bloquejos basats en spinlock utilitzats en les proves s'implementen a través d'un enllaç casolà que funciona en l'espai de l'usuari.
El programador de tasques pot prendre el control en qualsevol moment durant l'execució d'aquest enllaç i canviar a una altra tasca.
atès qui el mesurament de l'rendiment es basa en valors absoluts de l'temporitzador, Els retards definits en les proves cobreixen no només els retards en el controlador de bloqueig, sinó també el codi que es va executar en un context diferent, És a dir.
No només mesura el que l'autor de la prova va intentar mesurar, sinó també el «soroll» d'altres càlculs en el sistema.
El problema és que els desenvolupadors no haurien d'haver estat utilitzant spinlocks en primer lugar, per la qual cosa en el que respecta, no va ser el culpable el programador de Linux, sinó els enfocaments dels desenvolupadors per usar-lo.
L'autor de la prova va intentar objectar a Linus, assenyalant que l'ús de sistemes de bloqueig basats en spinlock patentats sovint s'usa en la pràctica en els jocs, ja que quan es fan servir programadors més simples que en Linux, les proves mostren un millor rendiment.
Linus esmento que el planificador de Linux és universal, Refinat durant dècades i optimitzat no només per a l'escriptori i els jocs, Sinó també per a altres tipus de càrregues de treball, per exemple, sistemes de servidor i per tant té en compte molts matisos a l'planificar les tasques.
Afegir optimitzacions específiques que reduiran la latència en els jocs de Google Stadia pot augmentar la capacitat de resposta en un cas particular, però és probable que redueixi el rendiment general de programador.
Per exemple, el programador de Windows es comporta millor en les proves en discussió, ja que és molt més simple que el programador de Linux i està optimitzat principalment per a tasques específiques de l'escriptori.
font: https://probablydance.com/