Chapitre 18 Fournisseur lockstat

Le fournisseur lockstat propose des sondes pouvant être utilisées pour dériver des statistiques de contention de verrou pour comprendre quasiment tous les aspects du comportement de verrouillage. La commande lockstat(1M) est véritablement un consommateur DTrace utilisant le fournisseur lockstat pour collecter ses données brutes.

Présentation

Le fournisseur lockstat propose les deux types de sonde suivants : sondes d'événement de contention et sondes d'événement de maintien.

Les sondes Événement de contention correspondent à la contention sur une primitive de synchronisation, et se déclenchent lorsqu'un thread est contraint d'attendre qu'une ressource soit disponible. Solaris est généralement optimisé pour une non-contention. Une contention prolongée n'est donc pas prévue. Ces sondes doivent être utilisées pour comprendre les cas où une contention se produit. La contention étant relativement rare, l'activation de sondes d'événement de contention n'affecte généralement pas la performance de manière significative.

Les sondes Événement de maintien correspondent à l'acquisition, la libération ou toute autre manipulation d'une primitive de synchronisation. Ces sondes peuvent être utilisées pour répondre à des questions arbitraires sur la manipulation des primitives de synchronisation. Solaris acquérant et libérant très souvent des primitives de synchronisation (de l'ordre de millions de fois par seconde et par CPU sur un système occupé), l'activation de sondes d'événement de maintien entraîne un effet de sonde supérieur à l'activation de sondes d'événement de contention. Alors que l'effet de sonde entraîné par leur activation peut être important, il n'est néanmoins pas pathologique. Elles peuvent toujours être activées en toute confiance sur des systèmes de production.

Le fournisseur lockstat propose des sondes correspondant aux différentes primitives de synchronisation de Solaris. Ces primitives et les sondes correspondantes sont expliquées dans ce chapitre.

Sondes de verrou adaptatif

Les verrous adaptatifs entraînent une exclusion mutuelle dans une section critique, et peuvent être acquis dans la plupart des contextes du noyau. Les verrous adaptatifs ne comprenant que très peu de restrictions liées au contexte, ils incluent une grande majorité de primitives de synchronisation du noyau Solaris. Ces verrous sont adaptatifs de par leur comportement vis-à-vis de la contention : lorsqu'un thread tente d'acquérir un verrou adaptatif maintenu, il détermine si le thread propriétaire est en cours d'exécution sur une CPU. Si le propriétaire est exécuté sur une autre CPU, le thread demandeur effectuera une rotation. Si le propriétaire n'est pas exécuté, le thread demandeur se bloquera.

Les quatre sondes lockstat appartenant à des verrous adaptatifs sont répertoriées dans le Tableau 18–1. Pour chaque sonde, arg0 contient un pointeur vers la structure kmutex_t qui représente le verrou adaptatif.

Sondes de verrou de rotation

Les threads ne peuvent pas bloquer dans certaines situations dans le noyau, comme en cas d'interruption à niveau élevé et tout autre cas de manipulation d'état de dispatcheur. Dans ces cas, cette restriction empêche l'utilisation de verrous adaptatifs. Les verrous de rotation sont plutôt utilisés, dans ces situations, pour effectuer une exclusion mutuelle dans des sections critiques. Comme leur nom l'indique, le comportement de ces verrous en cas de contention consiste à effectuer une rotation jusqu'à ce que le verrou soit libéré par le thread propriétaire. Les trois sondes appartenant aux verrouillages de rotation sont répertoriées dans le Tableau 18–2.

Les verrous adaptatifs sont bien plus fréquents que les verrous de rotation. Le script suivant affiche les totaux des deux types de verrou, proposant ainsi des données d'observation.

lockstat:::adaptive-acquire
/execname == "date"/
{
	@locks["adaptive"] = count();
}

lockstat:::spin-acquire
/execname == "date"/
{
	@locks["spin"] = count();
}

Exécutez ce script dans une fenêtre et une commande date(1) dans une autre. Une fois le script DTrace terminé, une sortie similaire à l'exemple suivant s'affiche :

# dtrace -s ./whatlock.d
dtrace: script './whatlock.d' matched 5 probes 
^C
spin                                                             26
adaptive                                                       2981

Comme illustré ici, plus de 99 % des verrous acquis lors de l'exécution de la commande date sont des verrous adaptatifs. Il peut être surprenant qu'un si grand nombre de verrous soit acquis avec une commande aussi simple que date. Le grand nombre de verrous est un artefact classique du verrouillage de précision nécessaire sur un système hautement évolutif comme le noyau Solaris.

Verrous de thread

Les verrous de thread sont un type spécifique de verrous de rotation utilisés pour verrouiller un thread en vue de changer son état. Les événements de maintien de verrou de thread sont disponibles sous forme de sondes d'événement de maintien de verrou de rotation (c'est-à-dire spin-acquire et spin-release), mais les événements de contention disposent de sondes propres spécifiques aux verrous de thread. La sonde d'événement de maintien de verrouillage de thread se trouve dans le Tableau 18–3.

Sondes de verrouillage en lecture/écriture

Les verrouillages en lecture/écriture appliquent une stratégie d'autorisation de plusieurs lecteurs ou d'un seul rédacteur — mais pas les deux — dans une section critique. Ces verrous sont généralement utilisés pour les structures plus fréquemment recherchées que modifiées et pour lesquelles la durée est importante dans la section critique. Si les durées de section critique sont courtes, les verrouillages en lecture/écriture sont implicitement placés en série sur la mémoire partagée utilisée pour mettre en œuvre le verrou, aucun avantage sur les verrous adaptatifs ne leur étant accordé. Pour plus d'informations sur les verrouillages en lecture/écriture, reportez-vous à rwlock(9F).

Les sondes appartenant à des verrouillages en lecture/écriture sont répertoriées dans le Tableau 18–4 Pour chaque sonde, arg0 contient un pointeur vers la structure krwlock_t qui représente le verrou adaptatif.

Stabilité

Le fournisseur lockstat utilise un mécanisme de stabilité DTrace pour décrire ses stabilités, comme illustré dans le tableau suivant. Pour plus d'informations sur le mécanisme de stabilité, reportez-vous au Chapitre39Stabilité.