La branche kill-the-bkl d'Ingo est un peu à l'abandon en fait.
Parce que le soucis c'est que dans cette branche, le BKL est transformé en mutex.
Ca permet de voir ce que ça donne lorsque le bkl est converti en verrou traditionnel.
Donc avec cette branche le noyau crash assez vite, dû au fait qu'on verrouille le gros
mutex recursivement et donc ça crée un interblocage.
Cette branche est (était?) un excellent outil parce que justement ça permettait de savoir où
ça crashait, et aussi de voir les problèmes d'inversion de dépendance (grace à lockdep) qui
ne peuvent pas être vérifiés avec le BKL normal.
En bref c'est un excellent outil pour débusquer la bête, par contre si cette branche venait
à être appliquée dans le noyau principal, ce serait un désastre pour sa stabilité :-)
Pour ce qui est de la branche reiserfs/kill-the-bkl http://git.kernel.org/?p=linux/kernel/git/frederic/random-tr(...) (dont je suis l'heureux papa :-), les performances sont bien meilleures lorsqu'il s'agit d'écritures parallèles sur différentes partitions, par contre sur une seule partition c'est pas encore ça.
Le soucis c'est que j'avais fait quelques optimisations qui ont fini par rattraper les performances de la version bkl, voire même de les dépasser dans la plupart des cas. Mais on a découvert plus tard que cette optimisation avait créé une inversion de dépendance de vérrou.
Il va donc falloir que je fasse quelques pas en arrière et trouver d'autres optimisations.
J'espère pouvoir en arriver à bout pour 2.6.33, normalement ça devrait aller.
Sinon les efforts concernant le balayage du bkl se sont egrainés, il ya eu quelques contributions par ci par là qui devraient faire leur chemin pour le noyau 2.6.32
En fait c'est vrai que le bkl a été dégagé de la plupart des coins du noyau, mais il reste encore beaucoup utilisé mine de rien, sporadiquement dans des coins lugubres du noyau (tty, block...). Et c'est un gros soucis pour les developpeurs du patch temps réels. En particulier parce qu'ils sont en train de faire plein d'efforts pour intégrer les patchs temps réels dans la branche principale. Ca va assez vite d'ailleurs, mais leur plus gros soucis c'est le bkl qui crée d'enormes latences. Dans la branche temps-réel, ils ont un patch pour ça qui rend le bkl préemptible. Mais Linus ne veut pas de ce patch parce que les gens ne trouverons plus de bonne raisons à se consacrer au balayage du bkl s'il l'applique, alors les développeurs temps réels n'ont rien d'autres à faire que de le dégager.
[^] # 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.
Parce que le soucis c'est que dans cette branche, le BKL est transformé en mutex.
Ca permet de voir ce que ça donne lorsque le bkl est converti en verrou traditionnel.
Donc avec cette branche le noyau crash assez vite, dû au fait qu'on verrouille le gros
mutex recursivement et donc ça crée un interblocage.
Cette branche est (était?) un excellent outil parce que justement ça permettait de savoir où
ça crashait, et aussi de voir les problèmes d'inversion de dépendance (grace à lockdep) qui
ne peuvent pas être vérifiés avec le BKL normal.
En bref c'est un excellent outil pour débusquer la bête, par contre si cette branche venait
à être appliquée dans le noyau principal, ce serait un désastre pour sa stabilité :-)
Pour ce qui est de la branche reiserfs/kill-the-bkl http://git.kernel.org/?p=linux/kernel/git/frederic/random-tr(...) (dont je suis l'heureux papa :-), les performances sont bien meilleures lorsqu'il s'agit d'écritures parallèles sur différentes partitions, par contre sur une seule partition c'est pas encore ça.
Le soucis c'est que j'avais fait quelques optimisations qui ont fini par rattraper les performances de la version bkl, voire même de les dépasser dans la plupart des cas. Mais on a découvert plus tard que cette optimisation avait créé une inversion de dépendance de vérrou.
Il va donc falloir que je fasse quelques pas en arrière et trouver d'autres optimisations.
J'espère pouvoir en arriver à bout pour 2.6.33, normalement ça devrait aller.
Sinon les efforts concernant le balayage du bkl se sont egrainés, il ya eu quelques contributions par ci par là qui devraient faire leur chemin pour le noyau 2.6.32
En fait c'est vrai que le bkl a été dégagé de la plupart des coins du noyau, mais il reste encore beaucoup utilisé mine de rien, sporadiquement dans des coins lugubres du noyau (tty, block...). Et c'est un gros soucis pour les developpeurs du patch temps réels. En particulier parce qu'ils sont en train de faire plein d'efforts pour intégrer les patchs temps réels dans la branche principale. Ca va assez vite d'ailleurs, mais leur plus gros soucis c'est le bkl qui crée d'enormes latences. Dans la branche temps-réel, ils ont un patch pour ça qui rend le bkl préemptible. Mais Linus ne veut pas de ce patch parce que les gens ne trouverons plus de bonne raisons à se consacrer au balayage du bkl s'il l'applique, alors les développeurs temps réels n'ont rien d'autres à faire que de le dégager.
Tiens par exemple Thomas Gleixner a ouvert une page là-dessus avec l'état d'avancement:
http://rt.wiki.kernel.org/index.php/Big_Kernel_Lock