En fait je bossais sur cette branche d'Ingo qui convertissait le BKL en mutex.
Et puis comme ma machine se figeait complètement dès qu'elle touchait à mes partitions reiserfs, je me suis dit que je commencerais bien par là. D'autant que j'avais déjà bossé un chouilla sur reiserfs (un parseur pour le Hachoir de Victor Stinner).
C'est là que la naiveté commence. Je pensais que construire un simple lock basé sur un mutex pouvant être verrouillé recursivement (donc juste avec un compteur de référence de vérrouillage en plus) suffirait pour l'affaire.
Mais non. Le bkl a d'autres propriétés lamentables que le fait de pouvoir être verrouillé recursivement: il est implicitement relaché lorsqu'une tâche dort, et réattribué lorsqu'elle se réveille. Ce qui n'est pas le cas d'un mutex.
Ce qui fait qu'il y a plein de parties dans reiserfs qui comptent sur le fait qu'en dormant à tel endroit, le vérrou du systeme de fichier est relaché laissant place à un autre utilisateur.
Un cas clinique: une partie du code tombe sur des données qui ont besoin d'être flushées (= écrites sur le disque) avant de continuer, alors il dort, le vérrou se relâche implictement, laissant la place à un thread spécifique qui va flusher justement. Car ce flusher a lui aussi besoin du vérrou pour accéder aux données à écrire.
Mais voilà, avec un mutex il faut relâcher le vérrou explicitement.
Et reiserfs est bourré d'endroits comme ça.
Mais bon la majeure partie de ce boulot est terminé.
L'autre problème c'est que le bkl est un spinlock, donc plus rapide qu'un mutex car le spinlock boucle et prend le vérrou dés qu'il peut, alors qu'un mutex va faire dormir le processus en attendant. D'un autre côté le mutex va permettre à un autre processus de s'executer, ce qui est bien en cas de vérrou vérouillé longtemps. Mais s'il n'est pas vérrouillé longtemps, on perd du temps à switcher d'un processus à un autre.
Bref, le mutex est un poil moins efficace (même si les mutex peuvent boucler depuis 2.6.30 dans certaines situations).
Donc le reste du boulot c'est rattrapper les pertes de performances induites par la conversion du bkl. Heureusement maintenant il y a perfcounters. Couplé avec ftrace, c'est un outil magique pour trouver les points faibles dans un code :-)
Un autre truc avec reiserfs: c'est l'un des derniers gros utilisateurs du bkl, donc sa dératisation est plutôt désirée. Même s'il n'est plus dans les systèmes de fichiers les plus utilisés, il reste encore beaucoup utilisé (la migration de système de fichiers sur plein de serveurs, ça peut coûter cher).
[^] # Re: Une coquille, une question
Posté par fweisbec . En réponse à la dépêche Nouvelle version 2.6.31 du noyau Linux. Évalué à 10.
En fait je bossais sur cette branche d'Ingo qui convertissait le BKL en mutex.
Et puis comme ma machine se figeait complètement dès qu'elle touchait à mes partitions reiserfs, je me suis dit que je commencerais bien par là. D'autant que j'avais déjà bossé un chouilla sur reiserfs (un parseur pour le Hachoir de Victor Stinner).
C'est là que la naiveté commence. Je pensais que construire un simple lock basé sur un mutex pouvant être verrouillé recursivement (donc juste avec un compteur de référence de vérrouillage en plus) suffirait pour l'affaire.
Mais non. Le bkl a d'autres propriétés lamentables que le fait de pouvoir être verrouillé recursivement: il est implicitement relaché lorsqu'une tâche dort, et réattribué lorsqu'elle se réveille. Ce qui n'est pas le cas d'un mutex.
Ce qui fait qu'il y a plein de parties dans reiserfs qui comptent sur le fait qu'en dormant à tel endroit, le vérrou du systeme de fichier est relaché laissant place à un autre utilisateur.
Un cas clinique: une partie du code tombe sur des données qui ont besoin d'être flushées (= écrites sur le disque) avant de continuer, alors il dort, le vérrou se relâche implictement, laissant la place à un thread spécifique qui va flusher justement. Car ce flusher a lui aussi besoin du vérrou pour accéder aux données à écrire.
Mais voilà, avec un mutex il faut relâcher le vérrou explicitement.
Et reiserfs est bourré d'endroits comme ça.
Mais bon la majeure partie de ce boulot est terminé.
L'autre problème c'est que le bkl est un spinlock, donc plus rapide qu'un mutex car le spinlock boucle et prend le vérrou dés qu'il peut, alors qu'un mutex va faire dormir le processus en attendant. D'un autre côté le mutex va permettre à un autre processus de s'executer, ce qui est bien en cas de vérrou vérouillé longtemps. Mais s'il n'est pas vérrouillé longtemps, on perd du temps à switcher d'un processus à un autre.
Bref, le mutex est un poil moins efficace (même si les mutex peuvent boucler depuis 2.6.30 dans certaines situations).
Donc le reste du boulot c'est rattrapper les pertes de performances induites par la conversion du bkl. Heureusement maintenant il y a perfcounters. Couplé avec ftrace, c'est un outil magique pour trouver les points faibles dans un code :-)
Un autre truc avec reiserfs: c'est l'un des derniers gros utilisateurs du bkl, donc sa dératisation est plutôt désirée. Même s'il n'est plus dans les systèmes de fichiers les plus utilisés, il reste encore beaucoup utilisé (la migration de système de fichiers sur plein de serveurs, ça peut coûter cher).