> Quelqu'un dans la salle peut commenter les résultats, la pertinence ou l'impertinence de ce benchmark ?
NB : Mysql a la réputation d'être très exigent en futex.
Petite intro sur les futex/spinlock.
Un futex est un verrou.
Imaginons :
étape 1- thread (a) obtient le futex F
étape 2- thread (b) demande le futex F et bloque
étape 3- thread (a) libère le futex F
étape 4- thread (b) obtient le futex F et continu
En première approche on peut se dire qu'à l'étape 2 le thread (b) est mis en sommeil. C'est obligatoire pour du mono-cpu. On a un changement de contexte (userland / kernel). Ce changement est cher, 1000 instructions machine voire plus. Sur les systèmes smp et s'il y a plus de cpu que de thread actif, le mieux est de faire tourner le thread (b) en boucle comme ça il continue dès que le futex est dispo.
Sans la pratique, il faut trouver un compromise entre les deux scénarios précédent (mise en sommeil et spinlock). Comme un changement de contexte est cher, on a un mix entre les deux. Lorsqu'un futex est demandé et qu'il est déjà utilisé, on boucle (spinlock) un petit moment (très court) au cas où le futex est libéré durant cette boucle. S'il n'est pas dispo, le thread passe en sommeil. C'est pertinant à faire si la boucle spinlock coûte moins cher qu'une mise en sommeil du thread puis réveille. Lorsque les futex sont pris un très court instant (ce que les développeurs essaient normalement de faire) et sur un système smp, les spinlock offrent un gain important.
J'imagine que durant le bench lorsque nombre de thread <= nombre coeur, lorsqu'un thread demande un futex il l'obtient de suite et s'il boucle dans un spinlock, c'est sans conséquence car sinon le cpu qui exécute le thread n'a rien à faire.
Les performances chutent lorsqu'il y a plus d'un thread par cpu et je pense que lorsqu'un thread demande un futex il ne l'obtient de suite. Le thread est dans le spinlock un très cours instant avant de passer en wait.
Les boucles spinlock sont extrèmement rapides. On a une dizaine d'instruction cpu par boucle. Mais si des options de DEBUG sont activés, ça peut être une tout autre histoire et on peut avoir une centaine d'instruction machine (en fait, j'en sais rien, mais c'est envisagable). On peut imagine que dans ce cas et pour ce bench, les cpu passent beaucoup de temps dans les spinlock.
Sous Fedora par défaut il y a d'activé CONFIG_DEBUG_SPINLOCK et CONFIG_DEBUG_SPINLOCK_SLEEP. Il faudrait un bench sans ses options.
# Re:
Posté par IsNotGood . En réponse au journal Un benchmark FreeBSD 7 (CURRENT) et Fedora Core 6. Évalué à 10.
NB : Mysql a la réputation d'être très exigent en futex.
Petite intro sur les futex/spinlock.
Un futex est un verrou.
Imaginons :
étape 1- thread (a) obtient le futex F
étape 2- thread (b) demande le futex F et bloque
étape 3- thread (a) libère le futex F
étape 4- thread (b) obtient le futex F et continu
En première approche on peut se dire qu'à l'étape 2 le thread (b) est mis en sommeil. C'est obligatoire pour du mono-cpu. On a un changement de contexte (userland / kernel). Ce changement est cher, 1000 instructions machine voire plus. Sur les systèmes smp et s'il y a plus de cpu que de thread actif, le mieux est de faire tourner le thread (b) en boucle comme ça il continue dès que le futex est dispo.
Sans la pratique, il faut trouver un compromise entre les deux scénarios précédent (mise en sommeil et spinlock). Comme un changement de contexte est cher, on a un mix entre les deux. Lorsqu'un futex est demandé et qu'il est déjà utilisé, on boucle (spinlock) un petit moment (très court) au cas où le futex est libéré durant cette boucle. S'il n'est pas dispo, le thread passe en sommeil. C'est pertinant à faire si la boucle spinlock coûte moins cher qu'une mise en sommeil du thread puis réveille. Lorsque les futex sont pris un très court instant (ce que les développeurs essaient normalement de faire) et sur un système smp, les spinlock offrent un gain important.
J'imagine que durant le bench lorsque nombre de thread <= nombre coeur, lorsqu'un thread demande un futex il l'obtient de suite et s'il boucle dans un spinlock, c'est sans conséquence car sinon le cpu qui exécute le thread n'a rien à faire.
Les performances chutent lorsqu'il y a plus d'un thread par cpu et je pense que lorsqu'un thread demande un futex il ne l'obtient de suite. Le thread est dans le spinlock un très cours instant avant de passer en wait.
Les boucles spinlock sont extrèmement rapides. On a une dizaine d'instruction cpu par boucle. Mais si des options de DEBUG sont activés, ça peut être une tout autre histoire et on peut avoir une centaine d'instruction machine (en fait, j'en sais rien, mais c'est envisagable). On peut imagine que dans ce cas et pour ce bench, les cpu passent beaucoup de temps dans les spinlock.
Sous Fedora par défaut il y a d'activé CONFIG_DEBUG_SPINLOCK et CONFIG_DEBUG_SPINLOCK_SLEEP. Il faudrait un bench sans ses options.