Rien d'officiel en tout cas.
Je pense que ça se fera au fur et à mesure, parce que aucune personne seule ne peut corriger chaque endroit où se trouve le Bkl.
Quand bien même il y a une aversion générale pour ce vérrou, son retrait dépend beaucoup de la motivation qu'ont les mainteneurs ayant des affinités avec les sous-systèmes concernés.
Je m'explique, le Bkl n'est pas seulement un verrou géant, c'est aussi et surtout une horreur sans nom:
- C'est un verrou qui peut être acquis et réaquis autant de fois par une même tâche autant de fois qu'elle le désire.
Par exemple, un spinlock ou un mutex du noyau linux n'autorisera _jamais_ un usage récursif.
L'usage typique est:
mutex_lock(&lock);
//code partie protégée
mutex_unlock(&lock);
On pourrait éventuellement s'attendre à ce que ce code soit légal dans un même
thread, car c'est possible de l'implémenter. Mais non et heureusement.
Or le Bkl autorise ça pour une même tâche, il y a même un indicateur dans la structure des tâches du noyau pour indiquer la profondeur courante du Bkl pour une tâche donnée
C'est horrible parce que le code qui a été écrit en suivant cette liberté désinvolte est maintenant très difficile à corriger. Il ne suffit plus de remplacer le bkl par un simple verrou normal, il faut carrément parfois réorganiser le code.
Un cas typique c'est reiserfs qui possède des pans entiers dépendants de cette logique de récursivité.
- Le bkl est libéré pour la tâche courante lorsque celle-ci appelle schedule() O_o
Ca signifie qu'à chaque fois qu'une tâche détenant le bkl veut dormir, elle lâche le bkl et n'importe qui peut le reprendre. Et quand la tâche se réveille (quand schedule() retourne) le bkl est relocké pour la tâche courante.
Ca non plus ça n'a rien à voir avec un mutex ou spinlock normal. Ca veut dire que si l'auteur du code a prévu un appel à schedule(), qu'est ce qu'il avait en tête: dormir en attendant une ressource? Dormir pour relâcher un peu le verrou et le donner à quelqu'un d'autres pendant quelques temps?
- $ git-grep -E "[^n]lock_kernel\(\)" | grep -v "Documentation" | wc -l
590
Il y a 590 appels au bkl egrainés un peu partout dans le noyau. Souvent, chaque sous-système possède ses propres spécialistes qui sont les plus compétents pour résoudre ce vieux schéma de synchronisation, pour intégrer un vrai schéma de protection des données bien réfléchi.
Mais le problème c'est que c'est chiant. Il faut parfois repenser la structure du code, repenser des interdépendances avec d'autres zones qui détiennent le Bkl etc...
Je pense que si tout le monde s'y mettait, ça se passerait bien mais bon c'est tout simplement chiant.
Ceci étant la branche kill-the-BKL d'Ingo Molnar est plutôt bien vue.
Il s'agit de transformer le bkl en un mutex géant (faisant ainsi perdre les propriétés de récursivité et de relâche par schedule()) et donc permettre à lockdep de vérifier les problèmes qui surviennent. Ca permet d'identifier les zones à problèmes particulières.
On dirait que la tendance est à la suppression petit à petit du Bkl.
Il a été supprimé de l'appel système fasync() par Jonathan Corbet. Il me semble aussi qu'il a été supprimé à certains endroits de la couche tty.
De toutes façons c'est une priorité pour la branche -rt, donc il finira par être éradiqué.
Dans cette branche, le bkl est transformé en Mutex (c'est un spinlock dans la branche principale). Il me semble que c'est pour faciliter le débuggage pour l'enlever.
Car pour l'instant c'est un raw_spinlock, c'est à dire un spinlock qui ne peut pas être tracé par lockdep (l'outil de vérification des verroux dans le noyau).
Mais j'ai l'impression que les foules ne se bousculent pas au portillon pour bosser dans cette branche. Ceci étant ça pourrait changer :-)
2) La seconde partie qui détaille les "grosses" nouveautés doit-elle être ullifiée ou pas ? Est-elle trop longue, pas assez longue, trop technique, pas assez technique, etc ?
Non. Elle est bien comme ça, pas besoin d'unifier ou de faire des parties et sous parties je pense. Quand au niveau technique je pense aussi que c'est suffisant, ceux qui voudront aller plus loin peuvent cliquer sur les liens des articles Lwn.
3) Il y a beaucoup de d'hyperliens dans ces dépêches sur le noyau (une centaine dans celle-ci). Est-ce que vous cliquez sur ces liens ou pas ? Si oui sur combien en moyenne ? Est-ce qu'il y en a trop ou non ?
Selon moi c'est très bien comme ça. D'autant qu'il y a beaucoup de référence à Lwn, ce qui me semble être la source la plus judicieuse.
5) Est-ce que vous avez des idées pour améliorer ces dépêches sur le noyau ?
Oui.
Tu évoques bien les évènements les plus importants du cycle (Btrfs, etc...) mais ça manque de petites épices croustillantes. J'entends par là des événements qui sont majoritairement évoqués sur LKML et un peu Lwn mais qui tendent à passer à la trappe lors des annonces de sorties de version.
Par exemple un changement qui, selon moi est majeur, c'est le travail qui a été effectué sur les mutex par Peter Zijlstra en début de cycle (un poil avant la sortie de -rc1). Les mutex ont maintenant un comportement heutistique: tantôt ils drement, tantôt ils se prennent pour des spinlocks en bouclant si l'actuel possesseur du verrou est bien en train de s'executer sur un autre processeur. Si le possesseur du verrou change ou s'il est en train de dormir, alors celui qui requiert le verrou va pioncer.
Ca a beaucoup amélioré les performances. dans certains cas. Cette idée vient de la branche -rt.
Il y a plein de petit événements comme ça, comme l'exhumation du patch -rt, les irqs threadées soumises pour la branche principale et qui ont de grandes chances d'être mergée pour 2.6.30, ce qui est un énorme pas en avant pour la branche -rt (en partie).
Bref, il manque quelques petits trucs comme ça.
Bon en même temps c'est difficile de tout prendre en compte, j'admets :-)
C'est le prix à payer lorsqu'on développe un projet pour le noyau sans travailler avec le reste de la communauté. Certes peut être qu'ils n'acceptaient pas de bosser sur une base bancale. Alors en ce cas il fallait envoyer des patchs pour virer ces mauvaises bases et les tourner petit à petit vers ce qu'ils voulaient tout en apportant régulièrement l'argumentation qui va avec.
C'est déjà parfois difficile de faire avaler aux mainteneurs un petit jeu de 10 petits patchs qui développe une idée travaillée de manière isolée sans en parler à la communauté. A moins d'avoir de la chance ou beaucoup d'expérience.
En règle générale, soit l'idée est carrément refusée, soit on applique les révisions des rélecteurs de patchs et on renvoie une nouvelle version de son jeu de patch, et on itère comme ça jusqu'à ce que ça plaise à tout le monde. On voit régulièrement passer, sur la mailing list de Linux, des patchs qui en sont à leur 5ème, 10 ème version. Enfin heureusement ce n'est pas toujours comme ça. Au delà de 5 itérations c'est quand même plus rare. Mais ça peut être comme ça au lancement d'un projet pour le kernel et après la suite du développement est souvent plus simple et plus fluide, une fois qu'on a compris comment accorder ses propres désirs avec la direction que veut prendre la communauté, on parvient à balancer des patchs qui sont inclus sans trop de besoin de correction.
Bref, je parlais là d'un petit jeu de 10 petits patchs. Mais leur truc est un pavé.
C'est difficile d'inclure un pavé dans le noyau, l'idéal étant d'inclure chaque fonctionnalité d'un projet petit à petit, en restant toujours très proche de la liste de diffusion. Si un changement nécessite d'un coup un gros patch, il faut toujours parler de son idée avant et voir l'avis des autres, au risque d'être frustré après avoir balancé un patch de plusieurs semaines de boulot sans en en avoir parlé avant.
Je connaissais blktrace mais pas les outils qui l'exploitaient... Ben dis donc, avec l'évolution
du tracing dans Linux on arrive à de belles choses. C'est qu'il devient de plus en plus introspectif le noyal... :-)
Tout à fait.
Le __init est un raccourci pour dire que le code de la fonction appartient à la section .init.text, permettant ainsi de libérer cette mémoire après l'appel de ces fonctions qui ne seront plus utilisées.
Là où se joue l'ordre d'appel c'est à la définition du device_initcall(fonction).
/*
* Early initcalls run before initializing SMP.
*
* Only for built-in code, not modules.
*/
#define early_initcall(fn) __define_initcall("early",fn,early)
/*
* A "pure" initcall has no dependencies on anything else, and purely
* initializes variables that couldn't be statically initialized.
*
* This only exists for built-in code, not for modules.
*/
#define pure_initcall(fn) __define_initcall("0",fn,0)
Le level définit l'ordre d'appel. Plus il est petit, plus l'appel se fait au début.
On commence par les early_initcall (avant que le multiprocesseur soit activé).
Ensuite viennent les fonctions du coeur du noyau, puis les éléments relatifs à l'architecture, puis les sous-systèmes, puis le système de fichier, etc....
Ce qui donnera une section .initcall0.init pour les pure_initcall, .initcall1.init pour le coeur du noyau etc....
Et voilà, les pointeurs de fonctions seront regroupés par sections et rangés dans le bon ordre :-)
Oui mais ça ne pose pas de problème.
Si C se synchronise, donc que C attends A et B, et que Z se synchronise un peu en même temps, donc qu'il attends A, B, et C, ça ne pose aucun soucis.
Hmm, par exemple tu imagines quoi comme problème qui pourrait arriver?
"bonne idée - et j'aime bien la manière d'amener ça petit à petit.
La plupart des tentatives précédentes de faire du démarrage parallèle avaient pour défaut de vouloir trop en faire d'un coup"
Il faut voir aussi que se pose un lourd problème de synchronisation.
Lancer des fonctions asynchrones, c'est bien mais il y a toujours des étapes précises à suivre, il faut lister les périphériques avant de leur attribuer un numéro d'inode, il faut lister les disques de stockage avant de se lancer sur le montage de systèmes de fichiers etc....
D'ou ce soucis de devoir "synchroniser" les appels asynchrones. Et ce n'est pas une tâche aisée car il faut être sûr d'avoir bien deréssé la liste de chacune des dépendances.
Et combien de temps avant qu'un nombre significatif de pilotes soit mis à jour avec l'API ? Et quand on utilise du vieux matos avec des pilotes qui n'évoluent plus trop ?
A mon avis ça va prendre du temps. Je pense même que seules certaines parties significatives, celles qui seront reconnues pour consommer beaucoup de temps d'execution, seront éventuellement adaptées en asynchrone, si tant est que fastboot trace bien son chemin.
Oui, effectivement cette phrase a l'air d'être teintée d'absolu, j'aurais du nuancer un peu plus le propos.
Même au niveau noyau, il y a bien d'autres enjeux pour raccourcir le temps de démarrage. D'ailleurs la discussion sur la dernière mouture de fastboot a soulevé de nouvelles questions sur le délai d'attente concernant les tests d'interruptions, la manière de dresser la liste des périphériques etc...
Pô mal hein?
Le but étant en fait d'analyser ce qui se passe lorsque fasboot est activé.
Fastboot étant une fonctionnalité du noyau permettant aux fonctions d'initialisation (initcalls) du
noyau de s'executer de manière de manière asynchrone, c'est à dire en même temps en quelques sortes, plutôt que de les executer les unes après les autres.
Par exemple quand un initcall bloque/dort en attente d'une opération d'entrée sortie, ou une allocation mémoire etc... ça permet à un autre initcall de prendre la main sur le processeur, permettant ainsi de gagner du temps sur la suite au lieu de laisser le processeur se tourner les pouces.
Et hop tu peux afficher ton svg avec ce que tu veux, Gimp, Firefox tc.... Dedans tu y verras un graph de boot....qui ne concerne que l'intérieur du noyal bien entendu!A savoir les différentes parties du noyau qui s'initialisent...
Je me permets une petite correction au niveau du tracing.
ftrace, Lttng, et systemtap sont présentés ici comme étant en compétition, or c'est faux, ils sont complémentaires. Et ils ont des rôles différents.
ftrace permet d'appliquer une fonction qui hooke quasiment toutes les fonctions du kernel. C'est lourd mais complet, tandis que les tracepoints ne s'appliquent qu'à des fonctions particulières.
Remarquez, ftrace permet aussi de ne tracer que certaines fonctions mais c'est un truc à régler côté utilisateur.
En somme les tracepoints sont prévus pour du débuggage chirugical. On vise une ou quelques fonctions mais c'est tout.
ftrace est plutôt prévu pour tracer massivement, ou tracer seulement certaines fonctions à partir de certains critères (du style avec expression régulière, en choisissant tel préfixe ou suffixe, ou encore tracer uniquement une tâche etc....)
Les tracepoints font partie du projet LTTng.
Pour ce qui est de systemtap c'est encore différent, il s'agit de scripts que l'on peut produire côté utilisateur et donc les instructions sont executées côté kernel.
Si vous êtes interessés, pour plus de détails, je vous conseille une interview de Mathieu Desnoyers: http://www.linuxfoundation.org/events/node/153 qui explique bien le caractère complémentaire de ces 3 systèmes.
Et enfin concernant le ring buffer, il n'est pas encore sans vérrou :-)
Il utilise des spinlocks en interne lors de l'insertion d'un évenement.
Et il ne le sera pas non plus pour le 2.6.29, par contre il y a de grandes chances pour 2.6.30 :-)
[^] # Re: le BKL
Posté par fweisbec . En réponse à la dépêche Sortie de Linux 2.6.29. Évalué à 10.
Je pense que ça se fera au fur et à mesure, parce que aucune personne seule ne peut corriger chaque endroit où se trouve le Bkl.
Quand bien même il y a une aversion générale pour ce vérrou, son retrait dépend beaucoup de la motivation qu'ont les mainteneurs ayant des affinités avec les sous-systèmes concernés.
Je m'explique, le Bkl n'est pas seulement un verrou géant, c'est aussi et surtout une horreur sans nom:
- C'est un verrou qui peut être acquis et réaquis autant de fois par une même tâche autant de fois qu'elle le désire.
Par exemple, un spinlock ou un mutex du noyau linux n'autorisera _jamais_ un usage récursif.
L'usage typique est:
mutex_lock(&lock);
//code partie protégée
mutex_unlock(&lock);
Mais si tu essaies:
mutex_lock(&lock)
//gnagnagna bidule chouette
mutex_lock(&lock); <--- ici un blocage (deadlock)
//gnagnagna2 prout
mutex_unlock(&lock);
mutex_unlock(&lock);
On pourrait éventuellement s'attendre à ce que ce code soit légal dans un même
thread, car c'est possible de l'implémenter. Mais non et heureusement.
Or le Bkl autorise ça pour une même tâche, il y a même un indicateur dans la structure des tâches du noyau pour indiquer la profondeur courante du Bkl pour une tâche donnée
// current->lock_depth = -1
lock_kernel(); // current->lock_depth = 0
//pouet
lock_kernel(); // current->lock_depth = 1 (on ne deadlock pas)
//flet
unlock_kernel(); // current->lock_depth = 0
unlock_kernel(); // current->lock_depth = -1
C'est horrible parce que le code qui a été écrit en suivant cette liberté désinvolte est maintenant très difficile à corriger. Il ne suffit plus de remplacer le bkl par un simple verrou normal, il faut carrément parfois réorganiser le code.
Un cas typique c'est reiserfs qui possède des pans entiers dépendants de cette logique de récursivité.
- Le bkl est libéré pour la tâche courante lorsque celle-ci appelle schedule() O_o
Ca signifie qu'à chaque fois qu'une tâche détenant le bkl veut dormir, elle lâche le bkl et n'importe qui peut le reprendre. Et quand la tâche se réveille (quand schedule() retourne) le bkl est relocké pour la tâche courante.
Ca non plus ça n'a rien à voir avec un mutex ou spinlock normal. Ca veut dire que si l'auteur du code a prévu un appel à schedule(), qu'est ce qu'il avait en tête: dormir en attendant une ressource? Dormir pour relâcher un peu le verrou et le donner à quelqu'un d'autres pendant quelques temps?
- $ git-grep -E "[^n]lock_kernel\(\)" | grep -v "Documentation" | wc -l
590
Il y a 590 appels au bkl egrainés un peu partout dans le noyau. Souvent, chaque sous-système possède ses propres spécialistes qui sont les plus compétents pour résoudre ce vieux schéma de synchronisation, pour intégrer un vrai schéma de protection des données bien réfléchi.
Mais le problème c'est que c'est chiant. Il faut parfois repenser la structure du code, repenser des interdépendances avec d'autres zones qui détiennent le Bkl etc...
Je pense que si tout le monde s'y mettait, ça se passerait bien mais bon c'est tout simplement chiant.
Ceci étant la branche kill-the-BKL d'Ingo Molnar est plutôt bien vue.
Il s'agit de transformer le bkl en un mutex géant (faisant ainsi perdre les propriétés de récursivité et de relâche par schedule()) et donc permettre à lockdep de vérifier les problèmes qui surviennent. Ca permet d'identifier les zones à problèmes particulières.
[^] # Re: le BKL
Posté par fweisbec . En réponse à la dépêche Sortie de Linux 2.6.29. Évalué à 5.
Il a été supprimé de l'appel système fasync() par Jonathan Corbet. Il me semble aussi qu'il a été supprimé à certains endroits de la couche tty.
De toutes façons c'est une priorité pour la branche -rt, donc il finira par être éradiqué.
Ingo molnar avait fait une sous branche exprès ("Kill-the-bkl") dans sa branche -tip:
http://git.kernel.org/?p=linux/kernel/git/tip/linux-2.6-tip.(...)
Dans cette branche, le bkl est transformé en Mutex (c'est un spinlock dans la branche principale). Il me semble que c'est pour faciliter le débuggage pour l'enlever.
Car pour l'instant c'est un raw_spinlock, c'est à dire un spinlock qui ne peut pas être tracé par lockdep (l'outil de vérification des verroux dans le noyau).
Mais j'ai l'impression que les foules ne se bousculent pas au portillon pour bosser dans cette branche. Ceci étant ça pourrait changer :-)
[^] # Re: Petites questions
Posté par fweisbec . En réponse à la dépêche Sortie de Linux 2.6.29. Évalué à 1.
# Hmm...
Posté par fweisbec . En réponse à la dépêche Conférence Mozilla / Libre en Fête à Belfort. Évalué à 1.
Ce genre de truc ne m'a jamais trop tenté (je veux dire, les install party) mais par contre je crois que j'irai tenter la tarte flambée du soir...
[^] # Re: Petites questions
Posté par fweisbec . En réponse à la dépêche Sortie de Linux 2.6.29. Évalué à 8.
Non. Elle est bien comme ça, pas besoin d'unifier ou de faire des parties et sous parties je pense. Quand au niveau technique je pense aussi que c'est suffisant, ceux qui voudront aller plus loin peuvent cliquer sur les liens des articles Lwn.
3) Il y a beaucoup de d'hyperliens dans ces dépêches sur le noyau (une centaine dans celle-ci). Est-ce que vous cliquez sur ces liens ou pas ? Si oui sur combien en moyenne ? Est-ce qu'il y en a trop ou non ?
Selon moi c'est très bien comme ça. D'autant qu'il y a beaucoup de référence à Lwn, ce qui me semble être la source la plus judicieuse.
5) Est-ce que vous avez des idées pour améliorer ces dépêches sur le noyau ?
Oui.
Tu évoques bien les évènements les plus importants du cycle (Btrfs, etc...) mais ça manque de petites épices croustillantes. J'entends par là des événements qui sont majoritairement évoqués sur LKML et un peu Lwn mais qui tendent à passer à la trappe lors des annonces de sorties de version.
Par exemple un changement qui, selon moi est majeur, c'est le travail qui a été effectué sur les mutex par Peter Zijlstra en début de cycle (un poil avant la sortie de -rc1). Les mutex ont maintenant un comportement heutistique: tantôt ils drement, tantôt ils se prennent pour des spinlocks en bouclant si l'actuel possesseur du verrou est bien en train de s'executer sur un autre processeur. Si le possesseur du verrou change ou s'il est en train de dormir, alors celui qui requiert le verrou va pioncer.
Ca a beaucoup amélioré les performances. dans certains cas. Cette idée vient de la branche -rt.
Il y a plein de petit événements comme ça, comme l'exhumation du patch -rt, les irqs threadées soumises pour la branche principale et qui ont de grandes chances d'être mergée pour 2.6.30, ce qui est un énorme pas en avant pour la branche -rt (en partie).
Bref, il manque quelques petits trucs comme ça.
Bon en même temps c'est difficile de tout prendre en compte, j'admets :-)
[^] # Re: Difficulté d'être inclu dans le noyau
Posté par fweisbec . En réponse à la dépêche La fin de Grsecurity ?. Évalué à 2.
# Le prix du développement out-of-tree
Posté par fweisbec . En réponse à la dépêche La fin de Grsecurity ?. Évalué à 10.
C'est déjà parfois difficile de faire avaler aux mainteneurs un petit jeu de 10 petits patchs qui développe une idée travaillée de manière isolée sans en parler à la communauté. A moins d'avoir de la chance ou beaucoup d'expérience.
En règle générale, soit l'idée est carrément refusée, soit on applique les révisions des rélecteurs de patchs et on renvoie une nouvelle version de son jeu de patch, et on itère comme ça jusqu'à ce que ça plaise à tout le monde. On voit régulièrement passer, sur la mailing list de Linux, des patchs qui en sont à leur 5ème, 10 ème version. Enfin heureusement ce n'est pas toujours comme ça. Au delà de 5 itérations c'est quand même plus rare. Mais ça peut être comme ça au lancement d'un projet pour le kernel et après la suite du développement est souvent plus simple et plus fluide, une fois qu'on a compris comment accorder ses propres désirs avec la direction que veut prendre la communauté, on parvient à balancer des patchs qui sont inclus sans trop de besoin de correction.
Bref, je parlais là d'un petit jeu de 10 petits patchs. Mais leur truc est un pavé.
C'est difficile d'inclure un pavé dans le noyau, l'idéal étant d'inclure chaque fonctionnalité d'un projet petit à petit, en restant toujours très proche de la liste de diffusion. Si un changement nécessite d'un coup un gros patch, il faut toujours parler de son idée avant et voir l'avis des autres, au risque d'être frustré après avoir balancé un patch de plusieurs semaines de boulot sans en en avoir parlé avant.
[^] # Re: Il ne reste plus qu'à...
Posté par fweisbec . En réponse à la dépêche L'évolution de Fastboot. Évalué à 2.
du tracing dans Linux on arrive à de belles choses. C'est qu'il devient de plus en plus introspectif le noyal... :-)
[^] # Re: Il ne reste plus qu'à...
Posté par fweisbec . En réponse à la dépêche L'évolution de Fastboot. Évalué à 8.
Ben merci pour ces compliments.
Je pense que j'en referai d'autres alors :-)
J'ai déjà une petite idée pour la prochaine dépêche :-)
[^] # Re: Fort intéressant...
Posté par fweisbec . En réponse à la dépêche L'évolution de Fastboot. Évalué à 6.
Le __init est un raccourci pour dire que le code de la fonction appartient à la section .init.text, permettant ainsi de libérer cette mémoire après l'appel de ces fonctions qui ne seront plus utilisées.
Là où se joue l'ordre d'appel c'est à la définition du device_initcall(fonction).
Voici un extrait de include/linux/init.h
#define __define_initcall(level,fn,id) \
static initcall_t __initcall_##fn##id __used \
__attribute__((__section__(".initcall" level ".init"))) = fn
/*
* Early initcalls run before initializing SMP.
*
* Only for built-in code, not modules.
*/
#define early_initcall(fn) __define_initcall("early",fn,early)
/*
* A "pure" initcall has no dependencies on anything else, and purely
* initializes variables that couldn't be statically initialized.
*
* This only exists for built-in code, not for modules.
*/
#define pure_initcall(fn) __define_initcall("0",fn,0)
#define core_initcall(fn) __define_initcall("1",fn,1)
#define core_initcall_sync(fn) __define_initcall("1s",fn,1s)
#define postcore_initcall(fn) __define_initcall("2",fn,2)
#define postcore_initcall_sync(fn) __define_initcall("2s",fn,2s)
#define arch_initcall(fn) __define_initcall("3",fn,3)
#define arch_initcall_sync(fn) __define_initcall("3s",fn,3s)
#define subsys_initcall(fn) __define_initcall("4",fn,4)
#define subsys_initcall_sync(fn) __define_initcall("4s",fn,4s)
#define fs_initcall(fn) __define_initcall("5",fn,5)
#define fs_initcall_sync(fn) __define_initcall("5s",fn,5s)
#define rootfs_initcall(fn) __define_initcall("rootfs",fn,rootfs)
#define device_initcall(fn) __define_initcall("6",fn,6)
#define device_initcall_sync(fn) __define_initcall("6s",fn,6s)
#define late_initcall(fn) __define_initcall("7",fn,7)
#define late_initcall_sync(fn) __define_initcall("7s",fn,7s)
Le level définit l'ordre d'appel. Plus il est petit, plus l'appel se fait au début.
On commence par les early_initcall (avant que le multiprocesseur soit activé).
Ensuite viennent les fonctions du coeur du noyau, puis les éléments relatifs à l'architecture, puis les sous-systèmes, puis le système de fichier, etc....
Ce qui donnera une section .initcall0.init pour les pure_initcall, .initcall1.init pour le coeur du noyau etc....
Et voilà, les pointeurs de fonctions seront regroupés par sections et rangés dans le bon ordre :-)
[^] # Re: Fort intéressant...
Posté par fweisbec . En réponse à la dépêche L'évolution de Fastboot. Évalué à 2.
En ce cas, il faut lancer Z avant C...
[^] # Re: Fort intéressant...
Posté par fweisbec . En réponse à la dépêche L'évolution de Fastboot. Évalué à 1.
Si C se synchronise, donc que C attends A et B, et que Z se synchronise un peu en même temps, donc qu'il attends A, B, et C, ça ne pose aucun soucis.
Hmm, par exemple tu imagines quoi comme problème qui pourrait arriver?
[^] # Re: Fort intéressant...
Posté par fweisbec . En réponse à la dépêche L'évolution de Fastboot. Évalué à 2.
En fait, en interne ces cookies ne représentent qu'un compteur interne.
A aura le cookie 0, B aura le cookie 1 et C aura 2.
Lorsque c appèle async_synchronize_cookie, il passe en paramètre son propre cookie, c'est à dire 2.
Puis async_synchronize_cookie va dormir tant que toutes les fonctions asynchrones ayant un cookie plus petit que 2 ne sont pas terminées.
Cette histoire de cookie-compteur permet de s'assurer du bon ordre au niveau de la synchronisation.
[^] # Re: Chapeau
Posté par fweisbec . En réponse à la dépêche L'évolution de Fastboot. Évalué à 7.
En réalité il ya déjà eu des tentatives de ce genre par le passé.
Je cite un message d'Ingo Molnar:
http://lkml.org/lkml/2008/7/20/24
Pour traduire un passage:
"bonne idée - et j'aime bien la manière d'amener ça petit à petit.
La plupart des tentatives précédentes de faire du démarrage parallèle avaient pour défaut de vouloir trop en faire d'un coup"
Il faut voir aussi que se pose un lourd problème de synchronisation.
Lancer des fonctions asynchrones, c'est bien mais il y a toujours des étapes précises à suivre, il faut lister les périphériques avant de leur attribuer un numéro d'inode, il faut lister les disques de stockage avant de se lancer sur le montage de systèmes de fichiers etc....
D'ou ce soucis de devoir "synchroniser" les appels asynchrones. Et ce n'est pas une tâche aisée car il faut être sûr d'avoir bien deréssé la liste de chacune des dépendances.
Et combien de temps avant qu'un nombre significatif de pilotes soit mis à jour avec l'API ? Et quand on utilise du vieux matos avec des pilotes qui n'évoluent plus trop ?
A mon avis ça va prendre du temps. Je pense même que seules certaines parties significatives, celles qui seront reconnues pour consommer beaucoup de temps d'execution, seront éventuellement adaptées en asynchrone, si tant est que fastboot trace bien son chemin.
[^] # Re: Importance
Posté par fweisbec . En réponse à la dépêche L'évolution de Fastboot. Évalué à 7.
Même au niveau noyau, il y a bien d'autres enjeux pour raccourcir le temps de démarrage. D'ailleurs la discussion sur la dernière mouture de fastboot a soulevé de nouvelles questions sur le délai d'attente concernant les tests d'interruptions, la manière de dresser la liste des périphériques etc...
[^] # Re: Captures d'écran du visualiseur de boot
Posté par fweisbec . En réponse à la dépêche Le noyau Linux 2.6.28 est disponible. Évalué à 4.
Le but étant en fait d'analyser ce qui se passe lorsque fasboot est activé.
Fastboot étant une fonctionnalité du noyau permettant aux fonctions d'initialisation (initcalls) du
noyau de s'executer de manière de manière asynchrone, c'est à dire en même temps en quelques sortes, plutôt que de les executer les unes après les autres.
Par exemple quand un initcall bloque/dort en attente d'une opération d'entrée sortie, ou une allocation mémoire etc... ça permet à un autre initcall de prendre la main sur le processeur, permettant ainsi de gagner du temps sur la suite au lieu de laisser le processeur se tourner les pouces.
[^] # Re: A propos du tracing
Posté par fweisbec . En réponse à la dépêche Le noyau Linux 2.6.28 est disponible. Évalué à 2.
[^] # Re: A propos du tracing
Posté par fweisbec . En réponse à la dépêche Le noyau Linux 2.6.28 est disponible. Évalué à 2.
[^] # Re: A propos du tracing
Posté par fweisbec . En réponse à la dépêche Le noyau Linux 2.6.28 est disponible. Évalué à 5.
Au démarrage du noyau, ajoute le paramètre initcall_debug.
Après démarrage, monte un repertoire debugfs:
mount -t debugfs /debug debug
Ensuite rends toi dans le repertoire scripts des sources de ton noyau, puis:
bootgraph.pl < /debug/tracing/trace > mon_graph.svg
Et hop tu peux afficher ton svg avec ce que tu veux, Gimp, Firefox tc.... Dedans tu y verras un graph de boot....qui ne concerne que l'intérieur du noyal bien entendu!A savoir les différentes parties du noyau qui s'initialisent...
# A propos du tracing
Posté par fweisbec . En réponse à la dépêche Le noyau Linux 2.6.28 est disponible. Évalué à 10.
ftrace, Lttng, et systemtap sont présentés ici comme étant en compétition, or c'est faux, ils sont complémentaires. Et ils ont des rôles différents.
ftrace permet d'appliquer une fonction qui hooke quasiment toutes les fonctions du kernel. C'est lourd mais complet, tandis que les tracepoints ne s'appliquent qu'à des fonctions particulières.
Remarquez, ftrace permet aussi de ne tracer que certaines fonctions mais c'est un truc à régler côté utilisateur.
En somme les tracepoints sont prévus pour du débuggage chirugical. On vise une ou quelques fonctions mais c'est tout.
ftrace est plutôt prévu pour tracer massivement, ou tracer seulement certaines fonctions à partir de certains critères (du style avec expression régulière, en choisissant tel préfixe ou suffixe, ou encore tracer uniquement une tâche etc....)
Les tracepoints font partie du projet LTTng.
Pour ce qui est de systemtap c'est encore différent, il s'agit de scripts que l'on peut produire côté utilisateur et donc les instructions sont executées côté kernel.
Si vous êtes interessés, pour plus de détails, je vous conseille une interview de Mathieu Desnoyers: http://www.linuxfoundation.org/events/node/153 qui explique bien le caractère complémentaire de ces 3 systèmes.
Et enfin concernant le ring buffer, il n'est pas encore sans vérrou :-)
Il utilise des spinlocks en interne lors de l'insertion d'un évenement.
Et il ne le sera pas non plus pour le 2.6.29, par contre il y a de grandes chances pour 2.6.30 :-)