Bien sûr que si. GCompris est un incontournable dans les logiciels éducatifs. Et libre en plus. Son dévelopeur mérite clairement sa place dans ce rapport.
Oui mais son argumentation concerne surtout l'usage du tracing pour implémenter seccomp. Et là je suis d'accord, c'est plutôt une mauvaise idée.
En revanche créer une nouvelle classe de hooks, parallèle aux tracepoints mais uniquement pour la sécurité et qui serait basée sur l'infrastructure de filtrage du tracing (qui peut être rendue générique pour ce genre de besoin), ça aurait pu être intéressant.
Ca avait été discuté un peu sur LKML mais malheureusement ça n'a pas pris...
Pour chaque syscall il y a un tracepoint à l'entrée qui renseigne sur ses paramètres et un tracepoint en sortie qui informe sur la valeur de retour.
Si ta distro est suffisamment récente, tu devrais les trouver dans /sys/kernel/debug/tracing/events/syscalls/
Les tracepoints d'entrée commencent par sys_enter et ceux de sortir sys_exit
C'est dommage qu'on ne se soit pas penché un peu plus sur la solution ftrace/perf. Il y a avait vraiment quelque chose à faire de ce côté là. Passer par l'interface de ftrace ou perf est probablement une mauvaise idée effectivement mais par contre son infrastructure de filtrage pouvait tout à fait être réutilisée.
Avec ça on pouvait introduire une nouvelle classe de hooks indépendante du tracing qui permettait, selon le filtrage défini, de rejeter ou non un syscall. Et ça pouvait également s'appliquer à des évènements autres que les syscalls, donc les possibilités étaient vraiment intéressantes.
Enfin bon. Je ne connais pas cette solution à base de filtres BPF, mais j'espère qu'elle fournira autant sinon plus de flexibilité.
> Par ailleurs, hier j'ai présenté SystemTap à HaxoGreen en rajoutant plus d'exemples
> d'utilisation de probing userland et d'utilisation de -g (pour modifier ce que le
> kernel/application fait plutôt que de juste observer): http://people.redhat.com/~akunysz
/systemtap-haxogreen-201007(...)
Sympa. Dommage qu'il manque un petit comparatif vite fait avec ftrace, lttng ou perf. Juste pour
dire qu'ils font pas du tout les mêmes trucs. Mais je chipote.
En tout cas l'équipe de Systemtap alloue beaucoup d'effort pour faire rentrer uprobes (les hooks userspace) dans la branche principale du noyau. Du coup, ya des chances que ça soit mergé avant la fin de l'année prochaine. Voire même encore avant.
Je suis content de voir qu'un projet libre qui grossit possède des origines universitaires françaises.
C'est pas une question de chauvinisme, mais ayant fréquenté pas mal le monde universitaire français, je le trouve pantouflard, alors que ça devrait briller de créativité.
On n'amène pas assez les étudiants à participer à des projets libres. Pourtant c'est ce qu'il y a de plus formateur, autant pour les étudiants que pour les profs. Et les facs en tireraient une plus grande experience et présence.
> SystemTap n'a aucune raison d'être intégré à Linux. C'est que de l'userland. Par contre
> SystemTap utilise kprobe, utrace et uprobe. S'il n'y a que kprobe, il ne sait que tracer le
> kernel, ce qui est déjà pas mal.
Systemtap veut être intégré dans Linux (j'entends par là utrace et uprobe) car maintenir des patchs kernel out-of-tree ça demande beaucoup de temps de maintenance, de gestion des versions, etc...
Aussi, il y a du code userland dans Linux, comme le repertoire tools/ qui heberge les outils clients pour perf events. Ca permet d'avoir un developpement très synchronisé avec les évolutions de Linux. Là encore Systemtap aurait probablement interêt à avoir un repertoire tools/stap.
> stap -g permet d'injecter du code C arbitraire. Donc tu fais *vraiment* ce que tu veux (y
> compris n'importe quoi).
Ah, ok je savais pas.
> On est d'accord que le cas que tu cites est plus adapté à un tracepoint statique. Mais si ce
> tracepoint n'existe pas et que tu ne peux pas te permettre de recompiler le noyau, stap -g
> permettrait de le faire aussi. Évidemment c'est pas forcément une bonne idée mais c'est
> faisable.
> Pour autant que je sache, stap -g fonctionne avec la branche principale sans soucis tant que > tu ne veux instrumenter que du code noy
Oui, mais SystemTap n'est pas intégré dans la branche principale.
Et il semble être encore loin de l'être!
>> Pour retrouver le nom de l'inode, on a besoin de le vérrouiller, d'appeler une fonction
>> pour chercher le dentry correspondant, de faire des copies, de déverrouiller et enfin
>> de décrémenter son compteur de référence.
>>
>> Impossible avec un tracepoint dynamique.
>
> C'est tout à fait possible mais ça devient effectivement assez compliqué et si un tracepoint
> statique existe pour cela, c'est bien évidemment préférable.
Ben je vois pas du tout comment ça peut être possible. Il faudrait passer par un script du genre systemtap, mais Systemtap ne va pas jusqu'à pouvoir verrouiller des spinlocks aléatoires ou autres trucs du style. Et puis heureusement d'ailleurs, ça dépasserait vraiment le cadre des tracepoints dynamiques.
stap -g peut déréférencer des pointeurs et faire ce que tu veux en C dynamiquement sans que le développeur initial ait eu à placer un tracepoint statique.
System tap en fait peut être une exploitation plus poussée oui. Mais dans la branche principale, c'est pas encore le cas.
Non, les statiques sont moins puissants parce qu'ils sont limités à ce que le développeur initial a prévu. Les dynamiques sont plus puissants parce qu'ils permettent d'observer tout et n'importe quoi mais ils sont potentiellement plus compliqués à utiliser puisqu'il faut se familiariser avec le code à tracer.
De ce côté là oui, les statiques sont moins puissants, je n'ai pas dit le contraire.
Mais les dynamique n'atteindront jamais la puissance des statiques en ce qui concerne les données à sortir.
Par exemple on a un tracepoint statique pour les évenements où un inode devient "dirty".
Pour retrouver le nom de l'inode, on a besoin de le vérrouiller, d'appeler une fonction pour chercher le dentry correspondant, de faire des copies, de déverrouiller et enfin de décrémenter son compteur de référence.
Impossible avec un tracepoint dynamique.
Il n'ont pas le même usage ni le même rôle, tout simplement.
Concernant l'utilité du tracing, c'est effectivement très varié. Chaque famille de tracepoint prend son sens dans un contexte différent. C'est aux developpeurs de leur donner du sens en écrivant les outils adaptés.
Prends par exemple les tracepoints de l'ordonnaceur de tâche. On a les suivants:
- context switch (tache A dort, tâche B prend la main)
- wakeup (tache A est mise en état "runnable")
- migrate (tache A est migrée du CPU x à CPU y)
Avec ça on peut analyser énormément de choses. On a un outil dans perf events qui s'appele "perf sched". Avec ça on peut tracer la latence de l'ordonnanceur: le temps maximum/moyen pour qu'une tâche, prête à être executée, est finalement executée. On pourrait aussi analyser l'efficacité des décisions de migration. Imagine que sur le CPU 0 on ait quatre tâches qui se battent en duel, et sur le CPU 1 une seule. Si cet état dure trop longtemps, ça signifie qu'il y a un soucis. Les tracepoints permettent d'analyser ce genre de comportement.
Mais le tracing peut aussi être utilisé pour du débuggage. Imagine que tu as un bug en ouvrant un fichier et que tu as besoin de voir quel chemin a été pris par le code.
Tu peux utiliser le function graph tracer pour determiner ce qui se passe à chaque appel de open:
# cd /debug/tracing/
# echo sys_open > set_graph_function
# echo function_graph > current_tracer
# less trace
0) | sys_open() {
0) | do_sys_open() {
0) | getname() {
0) 1.028 us | kmem_cache_alloc();
0) 0.924 us | strncpy_from_user();
0) 5.309 us | }
0) | alloc_fd() {
0) 1.028 us | _raw_spin_lock();
0) 0.991 us | expand_files();
0) 0.886 us | _raw_spin_unlock();
0) 6.931 us | }
0) | do_filp_open() {
0) | get_empty_filp() {
0) 1.622 us | kmem_cache_alloc();
0) | security_file_alloc() {
0) 0.804 us | cap_file_alloc_security();
0) 2.598 us | }
0) 9.536 us | }
0) | do_path_lookup() {
0) | path_init() {
0) 0.901 us | _raw_read_lock();
0) 0.991 us | _raw_read_unlock();
0) 4.994 us | }
Et là tu vois exactement ce qui se passe.
De plus il y a point de traçage statique et dynamique, quel sont les avantages/inconvénients de chacun ?
Les tracepoints statiques sont placés sur des endroits très stratégiques, pertinents pour le sous système en question. Ils permettent de couvrir la majorité des besoins de tracing.
Si quelqu'un veut observer un point moins stratégique, aller plus en profondeur, il peut définir un tracepoint dynamique.
Les statiques sont aussi plus "puissants" dans les données qu'ils peuvent remonter. On peut leur demander de déréférencer des pointeurs, observer des données à l'intérieur d'une structure...on peut leur demander de remonter tout ce qu'on veut en fait.
Les dynamiques n'ont pas encore cette puissance. On peut leur demander d'afficher quelques variables, pourvu qu'il s'agisse de simples entiers ou adresses. Mais déréférencer des pointeurs, on y est pas encore.
Donc les statiques sont plus puissants et précis dans les données qu'ils peuvent remonter, tandis que les dynamiques sont plus puissants dans le fait qu'ils peuvent être placés un peu n'importe où.
frédéric dit qu'"avoir des points de traçage statiques un peu partout dans le noyau n'enchantait pas grand monde dans la branche principale", mais pourquoi est-ce que maintenant ça ne les dérangent plus ?
Parce qu'avant, placer un tracepoint ne faisait que placer un tracepoint :-) C'est à dire que du code noyau pouvait demander à observer ce tracepoint etc...mais il n'y avait pas encore de code qui faisait ça.
Aujourd'hui, quand tu ajoutes un tracepoint, il est directement utilisable par le biais des outils de perf events, ou par debugfs. Tu peux l'activer/désactiver en passant par un fichier. Récupérer ses données formatées en ascii ou directement en binaire. Tu peux filter en utilisant des expressions conditionelles. Générer des scripts python/perl automatiquement pour les analyser, modifier ces scripts, etc....
Donc aujourd'hui, ils sont considérés comme utiles directement.
Sinon autre chose, à propos des "régressions" : est-ce que c'est une manière élégante de dire "bugs" ?
Quand quelque chose fonctionnait, et que soudain du nouveau code casse ce qui fonctionnait, ça s'appelle une regression. C'est le type de bug le plus redouté (avec les trous de sécurité)
C'est vrai, l'ordonnanceur est peut être pas le meilleur exemple pour ça. Je l'évoque juste parce que CFS a déjà eu le temps de murir et de se stabiliser un peu. Certes c'est encore loin d'être du code mammouth. Mais c'est pas non plus comme s'il venait à peine d'arriver, avec des bugs béants et de la viande fraiche :-)
Dans la partie "Contrôleur IO-Block", tu fais référence à CFS comme l'ordonnanceur IO par défaut. Je pense que tu voulais parler de CFQ. CFS c'est l'ordonnanceur de tâches. CFQ est un des ordonnanceurs IO.
Enfin bon je cherche des poux hein? Je suis bien evidemment complètement fan de cette dépêche :p
Conseiller swap prefetch à quelqu'un qui a des soucis de latence parce que ses programmes de bureau mettent du temps à charger après une grosse invasion dans le "page cache" (dur à une grosse écriture), ça me semble plutôt du texte utile. Même si ça m'etonnerais que ce patch s'applique proprement sur un noyau récent.
Sparse est effectivement un analyseur statique de code (backend). Mais kmemcheck et kmemleak sont dynamiques (font des vérifications pendant que le noyau tourne).
Le noyau est en fait truffé d'analyseur dynamiques.
Liste non-exhaustive:
Outils "j'me tourne les pouces et j'attends qu'on me detecte un problème":
- Lockdep: vérifie les dépendances des verroux, prévient des possibilités de deadlocks.
- Hung Task: Vérifie périodiquement les tâches qui sont bloquées en mode non-interruptible pendant trop longtemps
- Soft-lockup: Vérifie que la tache courrante a été changée durant les dix dernières secondes
- Nmi watchdog: Vérifie les hard lockups (coincé dans une interruption, ou code avec interruptions désactivées, ou deadlock de spinlock)
- Kmemcheck: Detecte usage de memoire non initializée (lecture avant toute écriture)
- Kmemleack: Detecte fuites de mémoires
- Poisons: D'une manière générale, les poisons sont des codes répétitifs qu'on insère dans un zone de mémoire libérée, comme par exemple une répétition de 0x66666
Lorsqu'on alloue une page mémoire et qu'elle a été modifiée (une partie des 666 a été modifiée), on le signale. Comme ça detecte les usages de pages libérées
- Fault injection: Provoque beaucoup d'échecs d'allocations mémoire pour voir comment le kernel s'en sort avec peu de mémoire.
Outils "ah zut faut encore que j'analyse les résultats":
- Ftrace
- Perf events
- Plein de trucs
Certains mainteneurs testent les patchs qu'on leur soumet, parfois 24h/24h comme Ingo Molnar qui teste des démarrages de configs de noyaux aléatoires automatiquement sur les arbres de developpement qu'il maintient.
Ceci étant, avant qu'un patch soit commité dans l'arbre d'un mainteneur, avant même qu'il ne soit testé, il est d'abord passé en revue, par un quidam lambda qui passe par là (et qui peut délivrer un tag Reviewed-by:), et/ou par un mainteneur.
C'est d'ailleurs souvent la chasse aux tags "Acked-by". Un diminutif pour acknowleged (inteprété ici comme "jugé acceptable par:"). Il s'agit d'un tag que donnent les mainteneurs d'un sous-système ou par simplement quelqu'un qui connait bien le code en question.
Lorsqu'il y a un patch un peu sensible à soumettre, parce qu'il modifie des fonctionnalités clés, les Acked-by sont souvent le passeport pour que ce patch puisse passer.
Et si personne ne se donne la peine de relire, commenter, "commiter" le patch en question, c'est Andrew Morton qui s'y colle :p
Donc voilà, en règle générale, il faut envoyer son patch avec:
- LKML et/ou la liste de diffusion du sous-système visé
- Les mainteneurs, ou n'importe quelle personne qui connait un peu le code en question (on peut regarder dans l'historique des fichiers modifiés avec git-log). Sinon il suffit simplement de lancer le script suivant: "scripts/get_maintainer.pl patch_a_soumettre"
Et ce sans compter les petites règles de base (Documentation/SendingPatches) et les règles moins de base (Documentation/DevelopmentProcess/) qui font qu'un patch est plus acceptable qu'un autre.
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).
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.
Marf, quelqu'un vient ici annoncer qu'un logiciel libre permettra d'apporter du soutien scolaire ludique (et non pas avec un vieux grimoire poussiéreux) pour tous, disponible pour n'importe quelle couche sociale (certes il faut un ordinateur) et toi tout ce que tu trouves à répondre c'est "Flash? Beurk"?
[^] # Re: Trop peu de femmes. Liste sexiste
Posté par fweisbec . En réponse à la dépêche 100 développeurs : la part belle à l’Open Source. Évalué à 3.
Oui enfin la proportion féminine des codeurs reste largement minoritaire. Et invoquer le machisme comme seule explication c'est un peu facile.
[^] # Re: l'auteur de Gcompris ?
Posté par fweisbec . En réponse à la dépêche 100 développeurs : la part belle à l’Open Source. Évalué à 2.
Bien sûr que si. GCompris est un incontournable dans les logiciels éducatifs. Et libre en plus. Son dévelopeur mérite clairement sa place dans ce rapport.
# Jean Delvare
Posté par fweisbec . En réponse à la dépêche 100 développeurs : la part belle à l’Open Source. Évalué à 1.
Jean Delvare mériterait d'être dans cette liste également. Il a beaucoup contribué au noyau Linux surtout dans les sous-systèmes i2c et hwmon.
[^] # Re: Dommage
Posté par fweisbec . En réponse à la dépêche Sandboxing fin dans le noyau linux : la saga des filtres seccomp. Évalué à 0.
Oui mais son argumentation concerne surtout l'usage du tracing pour implémenter seccomp. Et là je suis d'accord, c'est plutôt une mauvaise idée.
En revanche créer une nouvelle classe de hooks, parallèle aux tracepoints mais uniquement pour la sécurité et qui serait basée sur l'infrastructure de filtrage du tracing (qui peut être rendue générique pour ce genre de besoin), ça aurait pu être intéressant.
Ca avait été discuté un peu sur LKML mais malheureusement ça n'a pas pris...
[^] # Re: Comportement de ftrace
Posté par fweisbec . En réponse à la dépêche Sandboxing fin dans le noyau linux : la saga des filtres seccomp. Évalué à 5.
C'est pas du tout une question bête.
Pour chaque syscall il y a un tracepoint à l'entrée qui renseigne sur ses paramètres et un tracepoint en sortie qui informe sur la valeur de retour.
Si ta distro est suffisamment récente, tu devrais les trouver dans /sys/kernel/debug/tracing/events/syscalls/
Les tracepoints d'entrée commencent par sys_enter et ceux de sortir sys_exit
# Dommage
Posté par fweisbec . En réponse à la dépêche Sandboxing fin dans le noyau linux : la saga des filtres seccomp. Évalué à 2.
Très bon article.
C'est dommage qu'on ne se soit pas penché un peu plus sur la solution ftrace/perf. Il y a avait vraiment quelque chose à faire de ce côté là. Passer par l'interface de ftrace ou perf est probablement une mauvaise idée effectivement mais par contre son infrastructure de filtrage pouvait tout à fait être réutilisée.
Avec ça on pouvait introduire une nouvelle classe de hooks indépendante du tracing qui permettait, selon le filtrage défini, de rejeter ou non un syscall. Et ça pouvait également s'appliquer à des évènements autres que les syscalls, donc les possibilités étaient vraiment intéressantes.
Enfin bon. Je ne connais pas cette solution à base de filtres BPF, mais j'espère qu'elle fournira autant sinon plus de flexibilité.
[^] # Re: question
Posté par fweisbec . En réponse à la dépêche Sortie de SystemTap 1.3. Évalué à 2.
> d'utilisation de probing userland et d'utilisation de -g (pour modifier ce que le
> kernel/application fait plutôt que de juste observer): http://people.redhat.com/~akunysz
/systemtap-haxogreen-201007(...)
Sympa. Dommage qu'il manque un petit comparatif vite fait avec ftrace, lttng ou perf. Juste pour
dire qu'ils font pas du tout les mêmes trucs. Mais je chipote.
En tout cas l'équipe de Systemtap alloue beaucoup d'effort pour faire rentrer uprobes (les hooks userspace) dans la branche principale du noyau. Du coup, ya des chances que ça soit mergé avant la fin de l'année prochaine. Voire même encore avant.
[^] # Re: perf trace -s timechart.py
Posté par fweisbec . En réponse à la dépêche Nouvelle version 2.6.34 du noyau Linux. Évalué à 2.
# Cool
Posté par fweisbec . En réponse à la dépêche SIP Communicator et Google Summer of Code. Évalué à 1.
C'est pas une question de chauvinisme, mais ayant fréquenté pas mal le monde universitaire français, je le trouve pantouflard, alors que ça devrait briller de créativité.
On n'amène pas assez les étudiants à participer à des projets libres. Pourtant c'est ce qu'il y a de plus formateur, autant pour les étudiants que pour les profs. Et les facs en tireraient une plus grande experience et présence.
[^] # Re: À propos du tracing
Posté par fweisbec . En réponse à la dépêche Nouvelle version 2.6.33 du noyau Linux. Évalué à 2.
> SystemTap utilise kprobe, utrace et uprobe. S'il n'y a que kprobe, il ne sait que tracer le
> kernel, ce qui est déjà pas mal.
Systemtap veut être intégré dans Linux (j'entends par là utrace et uprobe) car maintenir des patchs kernel out-of-tree ça demande beaucoup de temps de maintenance, de gestion des versions, etc...
Aussi, il y a du code userland dans Linux, comme le repertoire tools/ qui heberge les outils clients pour perf events. Ca permet d'avoir un developpement très synchronisé avec les évolutions de Linux. Là encore Systemtap aurait probablement interêt à avoir un repertoire tools/stap.
> stap -g permet d'injecter du code C arbitraire. Donc tu fais *vraiment* ce que tu veux (y
> compris n'importe quoi).
Ah, ok je savais pas.
> On est d'accord que le cas que tu cites est plus adapté à un tracepoint statique. Mais si ce
> tracepoint n'existe pas et que tu ne peux pas te permettre de recompiler le noyau, stap -g
> permettrait de le faire aussi. Évidemment c'est pas forcément une bonne idée mais c'est
> faisable.
Wep.
[^] # Re: À propos du tracing
Posté par fweisbec . En réponse à la dépêche Nouvelle version 2.6.33 du noyau Linux. Évalué à 1.
Oui, mais SystemTap n'est pas intégré dans la branche principale.
Et il semble être encore loin de l'être!
>> Pour retrouver le nom de l'inode, on a besoin de le vérrouiller, d'appeler une fonction
>> pour chercher le dentry correspondant, de faire des copies, de déverrouiller et enfin
>> de décrémenter son compteur de référence.
>>
>> Impossible avec un tracepoint dynamique.
>
> C'est tout à fait possible mais ça devient effectivement assez compliqué et si un tracepoint
> statique existe pour cela, c'est bien évidemment préférable.
Ben je vois pas du tout comment ça peut être possible. Il faudrait passer par un script du genre systemtap, mais Systemtap ne va pas jusqu'à pouvoir verrouiller des spinlocks aléatoires ou autres trucs du style. Et puis heureusement d'ailleurs, ça dépasserait vraiment le cadre des tracepoints dynamiques.
[^] # Re: À propos du tracing
Posté par fweisbec . En réponse à la dépêche Nouvelle version 2.6.33 du noyau Linux. Évalué à 2.
System tap en fait peut être une exploitation plus poussée oui. Mais dans la branche principale, c'est pas encore le cas.
Non, les statiques sont moins puissants parce qu'ils sont limités à ce que le développeur initial a prévu. Les dynamiques sont plus puissants parce qu'ils permettent d'observer tout et n'importe quoi mais ils sont potentiellement plus compliqués à utiliser puisqu'il faut se familiariser avec le code à tracer.
De ce côté là oui, les statiques sont moins puissants, je n'ai pas dit le contraire.
Mais les dynamique n'atteindront jamais la puissance des statiques en ce qui concerne les données à sortir.
Par exemple on a un tracepoint statique pour les évenements où un inode devient "dirty".
Pour retrouver le nom de l'inode, on a besoin de le vérrouiller, d'appeler une fonction pour chercher le dentry correspondant, de faire des copies, de déverrouiller et enfin de décrémenter son compteur de référence.
Impossible avec un tracepoint dynamique.
Il n'ont pas le même usage ni le même rôle, tout simplement.
[^] # Re: À propos du tracing
Posté par fweisbec . En réponse à la dépêche Nouvelle version 2.6.33 du noyau Linux. Évalué à 6.
Prends par exemple les tracepoints de l'ordonnaceur de tâche. On a les suivants:
- context switch (tache A dort, tâche B prend la main)
- wakeup (tache A est mise en état "runnable")
- migrate (tache A est migrée du CPU x à CPU y)
Avec ça on peut analyser énormément de choses. On a un outil dans perf events qui s'appele "perf sched". Avec ça on peut tracer la latence de l'ordonnanceur: le temps maximum/moyen pour qu'une tâche, prête à être executée, est finalement executée. On pourrait aussi analyser l'efficacité des décisions de migration. Imagine que sur le CPU 0 on ait quatre tâches qui se battent en duel, et sur le CPU 1 une seule. Si cet état dure trop longtemps, ça signifie qu'il y a un soucis. Les tracepoints permettent d'analyser ce genre de comportement.
Mais le tracing peut aussi être utilisé pour du débuggage. Imagine que tu as un bug en ouvrant un fichier et que tu as besoin de voir quel chemin a été pris par le code.
Tu peux utiliser le function graph tracer pour determiner ce qui se passe à chaque appel de open:
# cd /debug/tracing/
# echo sys_open > set_graph_function
# echo function_graph > current_tracer
# less trace
0) | sys_open() {
0) | do_sys_open() {
0) | getname() {
0) 1.028 us | kmem_cache_alloc();
0) 0.924 us | strncpy_from_user();
0) 5.309 us | }
0) | alloc_fd() {
0) 1.028 us | _raw_spin_lock();
0) 0.991 us | expand_files();
0) 0.886 us | _raw_spin_unlock();
0) 6.931 us | }
0) | do_filp_open() {
0) | get_empty_filp() {
0) 1.622 us | kmem_cache_alloc();
0) | security_file_alloc() {
0) 0.804 us | cap_file_alloc_security();
0) 2.598 us | }
0) 9.536 us | }
0) | do_path_lookup() {
0) | path_init() {
0) 0.901 us | _raw_read_lock();
0) 0.991 us | _raw_read_unlock();
0) 4.994 us | }
Et là tu vois exactement ce qui se passe.
De plus il y a point de traçage statique et dynamique, quel sont les avantages/inconvénients de chacun ?
Les tracepoints statiques sont placés sur des endroits très stratégiques, pertinents pour le sous système en question. Ils permettent de couvrir la majorité des besoins de tracing.
Si quelqu'un veut observer un point moins stratégique, aller plus en profondeur, il peut définir un tracepoint dynamique.
Les statiques sont aussi plus "puissants" dans les données qu'ils peuvent remonter. On peut leur demander de déréférencer des pointeurs, observer des données à l'intérieur d'une structure...on peut leur demander de remonter tout ce qu'on veut en fait.
Les dynamiques n'ont pas encore cette puissance. On peut leur demander d'afficher quelques variables, pourvu qu'il s'agisse de simples entiers ou adresses. Mais déréférencer des pointeurs, on y est pas encore.
Donc les statiques sont plus puissants et précis dans les données qu'ils peuvent remonter, tandis que les dynamiques sont plus puissants dans le fait qu'ils peuvent être placés un peu n'importe où.
frédéric dit qu'"avoir des points de traçage statiques un peu partout dans le noyau n'enchantait pas grand monde dans la branche principale", mais pourquoi est-ce que maintenant ça ne les dérangent plus ?
Parce qu'avant, placer un tracepoint ne faisait que placer un tracepoint :-) C'est à dire que du code noyau pouvait demander à observer ce tracepoint etc...mais il n'y avait pas encore de code qui faisait ça.
Aujourd'hui, quand tu ajoutes un tracepoint, il est directement utilisable par le biais des outils de perf events, ou par debugfs. Tu peux l'activer/désactiver en passant par un fichier. Récupérer ses données formatées en ascii ou directement en binaire. Tu peux filter en utilisant des expressions conditionelles. Générer des scripts python/perl automatiquement pour les analyser, modifier ces scripts, etc....
Donc aujourd'hui, ils sont considérés comme utiles directement.
Sinon autre chose, à propos des "régressions" : est-ce que c'est une manière élégante de dire "bugs" ?
Quand quelque chose fonctionnait, et que soudain du nouveau code casse ce qui fonctionnait, ça s'appelle une regression. C'est le type de bug le plus redouté (avec les trous de sécurité)
[^] # Re: L'ordonnanceur stabilisé et mur ?
Posté par fweisbec . En réponse à la dépêche Nouvelle version 2.6.33 du noyau Linux. Évalué à 4.
Pas faux...
[^] # Re: L'ordonnanceur stabilisé et mur ?
Posté par fweisbec . En réponse à la dépêche Nouvelle version 2.6.33 du noyau Linux. Évalué à 9.
# CFS/CFQ
Posté par fweisbec . En réponse à la dépêche Nouvelle version 2.6.33 du noyau Linux. Évalué à 7.
Enfin bon je cherche des poux hein? Je suis bien evidemment complètement fan de cette dépêche :p
[^] # Re: Allonz-y Alonso
Posté par fweisbec . En réponse à la dépêche qBittorrent v2.0 est sorti. Évalué à 0.
[^] # Re: Les grosses copies de fichiers sous Linux
Posté par fweisbec . En réponse à la dépêche Nouvelle version 2.6.32 du noyau Linux. Évalué à 2.
[^] # Re: LinUS
Posté par fweisbec . En réponse à la dépêche Nouvelle version 2.6.32 du noyau Linux. Évalué à 1.
[^] # Re: LinUS
Posté par fweisbec . En réponse à la dépêche Nouvelle version 2.6.32 du noyau Linux. Évalué à 2.
Linus Torvalds: 0
[^] # Re: Tests automatiques ?
Posté par fweisbec . En réponse à la dépêche Nouvelle version 2.6.32 du noyau Linux. Évalué à 10.
Le noyau est en fait truffé d'analyseur dynamiques.
Liste non-exhaustive:
Outils "j'me tourne les pouces et j'attends qu'on me detecte un problème":
- Lockdep: vérifie les dépendances des verroux, prévient des possibilités de deadlocks.
- Hung Task: Vérifie périodiquement les tâches qui sont bloquées en mode non-interruptible pendant trop longtemps
- Soft-lockup: Vérifie que la tache courrante a été changée durant les dix dernières secondes
- Nmi watchdog: Vérifie les hard lockups (coincé dans une interruption, ou code avec interruptions désactivées, ou deadlock de spinlock)
- Kmemcheck: Detecte usage de memoire non initializée (lecture avant toute écriture)
- Kmemleack: Detecte fuites de mémoires
- Poisons: D'une manière générale, les poisons sont des codes répétitifs qu'on insère dans un zone de mémoire libérée, comme par exemple une répétition de 0x66666
Lorsqu'on alloue une page mémoire et qu'elle a été modifiée (une partie des 666 a été modifiée), on le signale. Comme ça detecte les usages de pages libérées
- Fault injection: Provoque beaucoup d'échecs d'allocations mémoire pour voir comment le kernel s'en sort avec peu de mémoire.
Outils "ah zut faut encore que j'analyse les résultats":
- Ftrace
- Perf events
- Plein de trucs
Certains mainteneurs testent les patchs qu'on leur soumet, parfois 24h/24h comme Ingo Molnar qui teste des démarrages de configs de noyaux aléatoires automatiquement sur les arbres de developpement qu'il maintient.
Ceci étant, avant qu'un patch soit commité dans l'arbre d'un mainteneur, avant même qu'il ne soit testé, il est d'abord passé en revue, par un quidam lambda qui passe par là (et qui peut délivrer un tag Reviewed-by:), et/ou par un mainteneur.
C'est d'ailleurs souvent la chasse aux tags "Acked-by". Un diminutif pour acknowleged (inteprété ici comme "jugé acceptable par:"). Il s'agit d'un tag que donnent les mainteneurs d'un sous-système ou par simplement quelqu'un qui connait bien le code en question.
Lorsqu'il y a un patch un peu sensible à soumettre, parce qu'il modifie des fonctionnalités clés, les Acked-by sont souvent le passeport pour que ce patch puisse passer.
Et si personne ne se donne la peine de relire, commenter, "commiter" le patch en question, c'est Andrew Morton qui s'y colle :p
Donc voilà, en règle générale, il faut envoyer son patch avec:
- LKML et/ou la liste de diffusion du sous-système visé
- Les mainteneurs, ou n'importe quelle personne qui connait un peu le code en question (on peut regarder dans l'historique des fichiers modifiés avec git-log). Sinon il suffit simplement de lancer le script suivant: "scripts/get_maintainer.pl patch_a_soumettre"
Et ce sans compter les petites règles de base (Documentation/SendingPatches) et les règles moins de base (Documentation/DevelopmentProcess/) qui font qu'un patch est plus acceptable qu'un autre.
[^] # 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).
[^] # 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
[^] # Re: Flash
Posté par fweisbec . En réponse à la dépêche Kidimath : le soutien en mathématiques par Sésamath. Évalué à -3.
Y'a des limites au snobisme des formats...
[^] # Re: le BKL
Posté par fweisbec . En réponse à la dépêche Sortie de Linux 2.6.29. Évalué à 2.
Je pense que les choses y évolueront par petites étapes. Est ce que ça vaut le coup d'écrire des dépêches là dessus?
Traduction: est ce que des lecteurs seraient interessés?