Le Blog de Thomas

Logiciels libres, Linux embarqué, et autres ...

Jour 1, Mercredi 20 Juillet: Conférences


On se réveille plus tôt que prévu à cause du décalage horaire qui déboussole un peu. Ensuite, on erre un peu dans le quartier à la recherche d'un endroit pour petit déjeuner. On découvre alors quelques jolis bâtiments du centre d'Ottawa, en particulier le parlement. Finalement, on trouve de quoi manger dans une librairie, et on s'aperçoit plus tard que c'est un Starbucks.

Ensuite, il faut rejoindre le lieu de la conférences. Au fil de nos errances dans les rues, on aperçoit deux personnes avec un t-shirt comportant une citation de Linus Torvalds au dos. On se lance donc dans une discrète filature pour suivre les deux gaillards qui nous indiqueront certainement le lieu des confs. Et effectivement, on trouve assez rapidement notre chemin. À l'enregistrement, je retrouve Michael Opdenacker, que j'avais brièvement rencontré aux RMLLs. On nous donne un joli badge, deux t-shirts et un programme des conférences. L'organisation est excellente.

Les conférences ont lieu dans un centre de congrès intégré dans un vaste centre commercial du centre d'Ottawa. Les quatre salles de conférences sont réparties sur trois étages. Celle du troisième étage est gigantesque, plus de 600 places. Au deuxième étage, il y a une salle plus petite pour les tutoriels, environ 40-50 places, avec dans un coin quelques canapés et fauteuils qui lui donnent une ambiance feutrée et agréable. Enfin, au premier étage, il y a deux salles de taille moyenne, je dirais 100-150 places, et surtout un grand hall avec plein de canapés, de fauteuils qui seront squattés toute la semaine par des dizaines (centaines ?) de gugus avec leur portable.

Ceux qui veulent voir à quelles conférences je suis allé peuvent consulter le planning. Les conférences en rouge sont celles auxquelles j'ai assisté. Merci à Lucas pour la suggestion !

Un BOFS un peu spécial... achat de Whisky ;-)
Un BOFS un peu spécial... achat de Whisky ;-)

À propos du planning, vous pouvez remarquer plusieurs choses intéressantes :

Les papiers des conférences sont disponibles sur le site Web du symposium en deux volumes.

Jonathan Corbet, a Linux 2.6 roadmap


Linux Weekly News
Linux Weekly News

La première conférence commence à 10h. C'est la seule conf à ce moment là, et l'audience est donc très importante. En plus, c'est Jonathan Corbet qui présente, celui qui s'occupe de Linux Weekly News, réputé pour son résumé hebdomdaire du développement noyau et un des auteurs de Linux Device Drivers. Je savais déjà que c'était quelqu'un de très bon, et la présentation a confirmé cela. Il a une très bonne vision de tout ce qui se passe dans le développement noyau et est capable de synthétiser toutes ces informations, d'en extraire des lignes directrices et d'en faire part au public. Le fait d'avoir une vision globale ne l'empêche pas d'avoir une très bonne compréhension du fonctionnement interne du noyau, comme l'atteste son travail sur Linux Device Drivers, mais aussi ses articles pointus sur un point précis du noyau qui paraissent dans LWN. Sa conférence s'intitulait The Linux 2.6 Roadmap (as drawn by a blind man) et les slides sont déjà disponibles.

Modèle de développement


Il commence la présentation par le modèle de développement du noyau. Il rappelle son fonctionnement avant le 2.6, avec les noyaux pair stables et les noyaux impairs instables. Mais ce modèle de développement n'était pas sans poser des problèmes : l'intégration de nouvelles fonctionnalités prenait trop de temps, car il fallait attendre la sortie du prochain noyau stable. Cela entrainait une certaine frustration auprès des développeurs (un point important dans le Libre !), et également obligeait les distributeurs (RedHat, Mandriva, Debian, etc.) à backporter de nombreuses fonctionnalités. Du coup, un grand nombre de noyaux très divergents et violemment patchés existaient, ce qui ne rendait pas le déboguage facile.

Le développement du noyau 2.6 suit un autre modèle : de nouvelles fonctionnalités sont ajoutées en permanence, et une nouvelle version sort environ chaque mois. L'intégration plus rapide des patches permet d'avoir un déploiement plus important plus rapidement, et permet d'avoir des développeurs heureux. Grâce à cela, en 6 mois, un quart du code source du noyau a été changé, et au Kernel Summit 2004, quand on demandait à Linus quand la branche 2.7 allait être ouverte, il répondait que pour l'instant, ce n'était pas prévu, vu que le modèle actuel fonctionnait bien.

Jonathan Corbet a également parlé des apports de BitKeeper dans l'organisation du développement. Cet outil, propriétaire mais à l'époque gratuit, a permis plusieurs choses :

Corbet résumé le processus d'intégration d'un patch de la manière suivante :
  1. Le patch est intégré dans l'arbre -mm maintenu par Andrew Morton. C'est en quelque sorte un remplacement de l'ancienne branche de développement
  2. Quand le patch est satisfaisant, il est intégré dans la branche principale maintenue par Linus
  3. Au bout d'un certain temps, Linus sort une release candidate contenant le patch
  4. Et encore plus tard, une vraie version stable sort avec le patch

Toutefois, Jonathan a identifié quelques problèmes:

Pour régler les problèmes de stabilité, des gens se sont portés volontaires pour s'occuper de ce que Linus appele le sucker tree. Actuellement, c'est Greg KH et Chris Wright qui prennent en charge ce sucker tree qui consiste à sortir des versions 2.6.X.Y contenant uniquement des corrections de bugs ou de sécurité par rapport à la version 2.6.X actuelle.

Jonathan est également revenu sur l'affaire BitKepper, c'est-à-dire l'arrêt de la version gratuite de cet outil de gestion de code source. Il a donné simplement quelques dates :

Ces quelques dates permettent de voir à quelle vitesse la communauté des développeurs noyau a réagit face au manque d'un outil. À partir des bouts de code initialement écrits par Linus, des dizaines de gens se sont mis à apporter des améliorations, à écrire des scripts d'automatisation, des interfaces graphiques, et toutes sortes de choses rendant l'outil réellement utilisable. Je suis personnellement vraiment impressionné par cette réactivité.

En ce qui concerne l'avenir de Linux, Jonathan admet que c'est difficile de prédire exactement ce qu'il va se passer. Néanmoins, il a détaillé plusieurs aspects du noyau ou de l'organisation du développement qui allait prochainement bouger :

Améliorations à venir


Au niveau de la VMM, il y aura des améliorations en ce qui concerne le fonctionnement sous pression mémoire (lorsqu'il y a peu de mémoire libre), et des améliorations sur les algorithmes de remplacement de page (choisir quelle page il faut swapper et quelle page il faut garder en mémoire). Jonathan a également parlé d'améliorations à venir en termes de scalabilité, de réseau (IPSec, Ipv6, DCCP) et des pilotes de périphériques.

Améliorations sur la latence et le temps-réel


Il a passé une partie de sa présentation sur le problème de la latence, et du travail d'Ingo Molnar à ce sujet. Il définit la latence comme le temps que met le système à répondre à un évènement et identifie deux types de latence :
la latence d'interruption (interrupt latency), c'est à dire le temps qu'il faut au système pour répondre à une interruption matérielle
la latence d'ordonnancement (scheduling latency), c'est à dire le temps qu'il faut pour qu'un processus de haute priorité qui passe dans l'état prêt arrive effectivement en exécution sur le processeur
Pour limiter la latence, il faut notamment travailler pour retirer le fameux BKL (Big-Kernel-Lock), un gros lock qui était utilisé dans les précédentes versions du noyau pour protéger un peu tout et n'importe quoi. Il faut également travailler sur la durée de prise des locks, en la limitant au maximum.

Une vue de Gatineau, au Québec, depuis Ottawa
Une vue de Gatineau, au Québec, depuis Ottawa

Il a bien entendu évoqué le travail d'Ingo Molnar à ce sujet. Le noyau utilise massivement les spinlocks pour protéger les structures de données des accès concurrents. Le problème, c'est que les threads possédant un spinlock ne peuvent pas être préemptés, et des processus sans relation peuvent se bloquer. L'approche d'Ingo Molnar est de remplacer les spinlocks par des mutex (un nouveau type de sémaphore). Ainsi, la contention ne bloque pas les processeurs, car le code possédant un lock peut être préempté. L'autre point traité par Ingo Molnar sont les gestionnaires d'interruption, qui ne peuvent pas être préemptés dans le noyau actuel. Ingo propose de les déplacer dans des threads noyau, qui eux sont préemptibles. Jonathan Corbet a également évoque les problèmes posés par les variables par-CPU (per-CPU variables) qui requièrent que la préemption soit désactivée, et également le fait que le mécanisme RCU (Read-Copy-Update) est difficile sans désactiver la préemption.

Toutefois, les développeurs noyau ne sont pas pleinement satisfait des patchs proposés par Ingo. Ils reprochent à ce patch d'être très intrusif et de rendre le code assez obscur. D'autre part, ils considèrent pour l'instant que c'est un changement trop important au regard du nombre de gens intéressés. Pour autant, des parties de ces patches ont déjà été intégrées, et le reste pourra venir au fur et à mesure.

Corbet a également parlé des solutions basées sur I-Pipe (interrupt pipe) utilisées dans Adeos et RTAI. Le principe est de remplacer le gestionnaire d'interruption de Linux par un pipeline de gestionnaires, ce qui permet de ne jamais désactiver les interruptions matérielles, et d'avoir des tâches de haute priorité qui s'exécute en dehors du noyau Linux. Il y a donc un temps de réponse à une interruption qui est déterministe, et le code est simple, facile à vérifier.

Le lecteur qui voudra en savoir plus sur les solutions de temps-réel sous Linux pourra se reporter ici, ici, ici, ou pourra consulter http://lwn.net/Articles/143323/ des différentes approches pour le temps réel sous Linux.

Virtualisation


Jonathan a ensuite brièvement abordé le sujet de la virtualisation, très à la mode durant ce Linux Symposium (pas loin de 8 ou 9 conférences sur ce sujet). Étrangement, il n'a pas évoqué User Mode Linux, déjà intégré dans le noyau 2.6 depuis le 2.6.9, il a seulement parlé de Xen, qui est en attente d'intégration. Un court résumé de ce qui s'est dit au Kernel Summit est disponible sur LWN.

Système de fichiers


Au niveau des systèmes de fichiers, il a parlé de ReiserFS 4, un système de fichiers rapide, transactionnel et interesting (dixit Corbet). Il stocke les attributs en tant que fichiers et dispose d'un mécanisme pour des fichiers multi-flux. Il dispose également d'une architecture de plugin pour étendre ses fonctionnalités. Un article de LWN résume et détaille ces différentes fonctionnalités. Toutefois, ReiserFS 4 n'est pas pour l'instant intégré au noyau car il pose des problèmes d'intégration. Le patch est assez intrusif : il modifie des parties du VFS (Virtual Filesystem). Toujours au sujet des systèmes de fichiers, il a brièvement évoqué FUSE qui permet d'écrire des systèmes de fichiers en espace utilisateur, comme ftps ou sshfs. Le patch est sur le point d'être intégré, il restait quelques derniers points à régler avant cela. Enfin, il a parlé de v9fs, une implémentation du système de fichiers de Plan 9 pour Linux. Il n'a pas donné plus de détails, car une http://www.linuxsymposium.org/2005/view_abstract.php?content_key=128 était prévue durant le symposium. D'ailleurs, une conférence sur Plan 9 a également eu lieu pendant les Rencontres Mondiales du Logiciel Libre cette année, voir http://thomas.enix.org/Blog-20050711200624-Libre, ainsi que les slides de la présentation de Charles Forsyth.
Il a ensuite embrayé sur les système de fichiers pour clusters, un sujet également à la mode. GFS, de chez RedHat, et OCFS2, de chez Oracle, souhaitent tous deux voir leur système de fichiers pour clusters intégré au noyau. Chaque système de fichiers utilise son propre gestionnaire de verrous distribué (DLM, Distributed Lock Manager), et les développeurs noyau souhaiteraient qu'ils en utilisent un commun. Du travail est en cours pour définir le dénominateur commun permettant à GFS et OCFS2 d'utiliser le même DLM. Il faudra également définir quelles parties d'une solution de cluster doivent être intégrées au noyau, et quelles parties doivent rester en espace utilisateur. Le lecteur désireux d'en savoir plus pourra regarder par ici pour OCFS2 et par http://lwn.net/Articles/144274/ pour avoir un résumé de ce qui s'est dit au Kernel Summit sur la question.

Linux prêt pour le desktop ?


Au niveau des fonctionnalités du noyau Linux pour le desktop, Jonathan a parlé de l'intégration dans le 2.6.13 de inotify. Il s'agit d'un mécanisme qui permet aux applications utilisateur de surveiller des évènements intervenant sur des fichiers. Ainsi, un gestionnaire de fichiers peut surveiller les fichiers qu'il affiche, et rafraichir automagiquement les miniatures lorsque le fichier change. Inotify vise à remplacer dnotify, avec une interface plus propre et surtout avec moins de problèmes en ce qui concerne les médias amovibles. Il a également parlé de Software Suspend qui permet de suspendre une machine, soit en RAM, soit sur le disque. Il n'y aurait pas pour l'instant de volonté d'intégrer cela dans la branche principale du noyau, car il reste encore du travail pour stabiliser la chose. Enfin, il a évoqué le support des cartes graphiques, qui nécessite un peu de ménage.

Sécurité


Au niveau sécurité, il a bien entendu parlé de SELinux, qui est devenu LE framework de sécurité. D'ailleurs, les développeurs noyau commencent à se demander si ils ne vont pas retirer le support pour les autres frameworks de sécurité vu que SELinux semble être la solution faisant désormais l'unanimité. Toujours à propos de sécurité, Jonathan a évoqué le support des puces TPM pour le Trusted Computing. Le lecteur intéressé pourra consulter le compte-rendu rédigé par Jonathan de la conférence Trusted Computing and Linux sur le sujet ayant eu lieu pendant le symposium.

Jonathan a parlé de CKRM, Class-based Kernel Resource Management, mais je n'en ai pas retenu grand chose. Le lecteur intéressé pourra consulter le site officiel.

Gestion du temps


Arrivée au Québec, de l'autre coté du fleuve par rapport à Ottawa
Arrivée au Québec, de l'autre coté du fleuve par rapport à Ottawa

Puis, la gestion du temps a été abordée. Récemment, un patch permettant de configurer la constante HZ a été intégré dans le noyau. HZ est la constante qui détermine le nombre d'interruptions horloge effectuées chaque seconde. Sous Linux 2.4 architecture x86, c'était 100 Hz et sous Linux 2.6 architecture x86, c'était 1000 Hz. La valeur de cette constante est un compromis à trouver entre un bon temps de réponse (nécessitant des valeurs hautes de HZ), et la quantité de temps passée à traiter les interruptions horloge (nécessitant des valeurs basses de HZ). En effet, si HZ=1000, alors on exécute 1000 fois par seconde le gestionnaire d'interruption horloge, si HZ=100, on l'exécute 10 fois moins souvent. Le code de gestion du temps est en cours de réécriture par John Stultz qui donnait d'ailleurs une http://www.linuxsymposium.org/2005/view_abstract.php?content_key=199 à ce sujet. Le lecteur intéressé pourra lire le papier de la conférence ou alors cet article de LWN. Cette problématique de gestion du temps intéresse également les gens de l'embarqué, qui se demandent même si le “tick” d'horloge est vraiment nécessaire. Dans les sytèmes embarqués pour lesquels l'économie d'énergie est primordiale, ce “tick” est ennuyeux : même si il n'y a aucune tâche qui s'exécute, le processeur est réveillé 1000 fois par seconde pour constater qu'il n'y a rien à faire. Des gens ont ainsi proposé de rendre cette valeur dynamique, afin de réveiller le processeur moins souvent quand il n'y a rien à faire (voir ce site pour les patches en question).

Enfin, le problème de la fragmentation mémoire a été abordé. Je le détaillerai plus tard dans le résumé de la conférence « Can you handle the pressure? Making Linux bulletproof under load »

Conclusion


Et Jonathan conclut par un

« Linux will still be fun »

Cette conférence était vraiment excellente. De nombreux points ont été abordés, et pour chacun d'entre eux, Jonathan a su donner un aperçu technique précis. Je suis vraiment impressionné par ce bonhomme.

NKLD : Novell Linux Kernel Debugger


Le déboguage dans le noyau est une tâche délicate, bien plus délicate que le déboguage d'applications utilisateur. En effet, lorsqu'un problème survient dans du code noyau, en général, tout le système est à plat, et il est difficile d'investiguer. Lorsqu'il s'agit d'un crash, le système affiche son état et s'arrête, tout simplement. S'ensuit alors une longue phase d'investigation pour essayer de déterminer l'origine du problème.

Pour les applications utilisateur, on dispose de débogueurs qui simplifient grandement la tâche. Au niveau noyau, il existe quelques débogueurs : KDB, KGDB et NLKD qui était celui présenté. Les slides de cette présentation sont disponibles, ainsi que le papier.

NLKD est utilisé en interne par Novell depuis 1998, mais c'est seulement en 2004 qu'ils ont décidé de diffuser le code source afin de diffuser cette technologie, et d'aller faire une possible intégration dans la branche principale du noyau.

Tout d'abord, le présentateur a parlé des difficultés dans l'implémentation d'un débogueur noyau par rapport à un débogueur d'application utilisateur : en particulier, gérer le multi-processeur, s'assurer qu'il n'y a pas d'effets de bord, etc. NLKD est composé de trois parties:

Le présentateur fait une démo en direct du débogueur, alors qu'il est en train de faire fonctionner OpenOffice, ce qui montre que la chose doit être plutôt stable. L'interface montrée est celle du console debug agent (le remote debug agent s'utilise via gdb). C'est une interface en mode texte qui peut s'afficher par dessus ce qu'affiche X (si le mode framebuffer et le mode X choisis sont compatibles). L'interface permet de visualiser le code, les données, la mémoire, la pile et les registres. Elle permet d'évaluer des expressions, faire des conversions de base, etc. L'interface a l'air bien pensée, on peut redimensionner les différents panneaux, faire apparaître de nouveaux panneaux avec plus d'informations. En tout cas, dans les mains du présentateur, ça semble simple à utiliser, avec plein de raccourcis clavier.

La zone d'affichage du code permet de suivre les appels et les retours de fonction, ce qui est plutôt sympathique. Des évènements peuvent automagiquement appeler le débogueur. Pour la démo, le présentateur a demandé à ce que le débogueur soit appelé lorsqu'un nouveau thread est créé. Il a alors bricolé deux trois choses dans OpenOffice, et paf, au moment de la création d'un thread, le débogueur a pris la main. On peut évidemment placer des points d'arrêt, exécuter le code pas-à-pas. Le débogueur a une connaissance de certaines structures de données du noyau pour rendre le déboguage plus aisé. En particulier, il connaît la structure d'un thread et la structure d'un module noyau.

En résumé, la présentation était plutôt convaincante : l'outil a l'air complet et utilisable. Évidemment, c'est un débogueur, donc c'est un outil qui doit nécessiter un certain temps de formation avant d'être réellement utile, mais la présentation donne vraiment envie de tester !

Déjeuner


Hmm, le fast-food
Hmm, le fast-food

Le centre de congrès étant situé dans un centre commercial, il n'est pas difficile de trouver à manger. En particulier, il y a une sorte de grand espace avec plein de tables et de chaises, et tout un tas de fast-food autour qui se partagent l'espace de tables et de chaises. C'est assez particulier, et je ne crois pas que ce soit courant en France. En gros, chacun peut aller dans le fast-food de son choix, mais tout le mode peut manger ensemble. Il y a l'embarras du choix : les classiques hamburgers, de la nourriture japonaise ou italienne, ou encore d'autres choses louches. Tant qu'à être en Amérique du Nord, autant manger local: fast-food ;-)

Pour ce premier midi, on s'est laissé tenté par un petit KFC avec un hamburger bien artificiel. J'ai demandé un jus d'orange et je me suis retrouvé avec une boisson orange fluo qui n'a jamais du voir une orange de sa vie. D'ailleurs, ça se sentait au goût, j'avais l'impression de boire un médicament infame. C'était pire que de l'Oasis, et ils font vraiment pas d'effort pour que la couleur ressemble de près ou de loin à un vrai jus d'orange, comme vous pouvez le constater sur la photo. Bref, miam miam.

Using genetic algorithms to automatically tune the kernel


KernelTrap en avait parlé et j'avais transmis la nouvelle sur LinuxFr : un ingénieur d'IBM a travaillé sur des algorithmes génétiques pour améliorer automatiquement et dynamiquer les performances du noyau Linux. http://fr.wikipedia.org explique ce qu'est un http://fr.wikipedia.org/wiki/Algorithme_g%C3%A9n%C3%A9tique, donc je ne vais pas revenir dessus (d'autant plus que l'article de Wikipédia est sans aucune doute beaucoup plus complet que mes maigres connaissances en la matière).

En gros, l'objectif des travaux de Jake Moilanen est de jouer sur les paramètres de l'ordonnanceur de processus (5-6 paramètres à ce niveau) et de l'ordonnanceur d'entrées sorties (3 paramètres à ce niveau) pour maximiser les performances du noyau. L'algorithme réalise un certain nombre de mesures pour déterminer si les performances du système d'améliorent ou se dégradent, et en fonction de ça, peut réaliser des choix. Jake a pu mesurer une amélioration des performances comprise entre 1 et 5%, ce qui n'est pas énorme, mais il reste beaucoup d'idées pour améliorer la chose. Je pense que pour l'instant, c'était surtout une proof-of-concept.

L'idée d'utiliser des algorithmes génétiques est intéressante. En effet, le noyau est un système complexe possédant de nombreux paramètres pour lesquels il est difficile de déterminer une valeur optimale pour tous les types de charge de travail. Cette détermination de la valeur optimale est d'autant plus délicate que le lien entre la valeur d'un paramètre et les conséquences sur les performances est difficile à établir. Dans tous les systèmes complexes avec de nombreux paramètres, les algorithmes évolutionnistes comme les algorithmes génétiques peuvent être utiles.

Dans le cadre du noyau néanmoins, c'est assez délicat : lorsque l'on modifie les paramètres, il faut attendre un certain temps pour pouvoir mesurer les effets de ces modifications. Pour cette raison, la convergence vers les paramètres optimaux est assez lente, ce qui est ennuyeux lorsque la charge de travail change rapidement. En effet, dans ces cas là, le système n'a pas le temps de s'adapter à la charge de travail que celle-ci a déjà changé. Pour pallier à ce problème, Jake propose par exemple d'injecter des gènes pertinents (connus à l'avance) par rapport à la charge de travail. Ceci devrait permettre d'accélérer la convergence vers les paramètres optimaux.

Il reste donc beaucoup d'améliorations possibles, de voies à explorer. Au delà de leur utilisation au niveau de l'ordonnanceur de processus et de l'ordonnanceur d'entrées-sorties, les algorithmes génétiques peuvent être utiles dans tous les systèmes complexes ayant de nombreux paramètres dont les valeurs sont difficiles à fixer empiriquement.

Pour en savoir plus, le lecteur pourra consulter le site de Jake Moilanen, ainsi que le papier, disponible à la page 327 du premier volume des proceedings.

SNAP Computing and the X Window System


Cette http://www.linuxsymposium.org/2005/view_abstract.php?content_key=102 a été donnée par Jim Gettys. Jim Gettys travaille sur X Window avec Keith Packard et est le rédacteur de la spécification de HTTP/1.1. Bien que je ne me sois pas rendu à cette conférence, je la mentionne car LWN en fait un compte-rendu assez intéressant.

Examining Linux 2.6 Page Cache Performance


Cette http://www.linuxsymposium.org/2005/view_abstract.php?content_key=47 avait pour objectif de relater les travaux d'analyse réalisés sur les performances du page cache du noyau Linux 2.6.

Pour ceux qui ne connaissent pas, le page cache est un ensemble de pages mémoire dans lesquelles sont stockées le contenu des blocs du disque les plus récemment accédés. Par exemple, lorsque vous lisez un fichier une première fois, la partie du fichier correspondante est chargée en mémoire. Tous les futurs accès à cette partie du fichier se feront en mémoire, que ce soit les accès en lecture ou en écriture. La mémoire agit comme un cache pour le disque, cache qui évite d'avoir à faire inlassablement des accès coûteux aux disques. De temps à autre, les modifications effectuées en mémoire sont reportées sur le disque. D'ailleurs, c'est ce page cache qui explique qu'il ne faut pas rebooter sauvagement une machine : certaines modifications effectuées dans le cache pourraient ne pas avoir été reportées sur le disque. Il est donc important avant de redémarrer une machine de démonter les systèmes de fichiers, ce qui aura pour effet de flusher le cache, c'est à dire de synchroniser le contenu du cache avec le contenu du disque. Ce cache explique aussi que dans /proc/meminfo vous ne voyez que très peu de mémoire libre. Par exemple, sur ma machine:
thomas@crazy:~$ cat /proc/meminfo 
MemTotal:       516068 kB
MemFree:          5968 kB

Il n'y a que 5 Mo de mémoire libre sur 516 Mo. En réalité, une grande partie de la mémoire est utilisée pour le page cache, et c'est tant mieux. Plus il y a de place pour le page cache, plus on pourra cacher des données en mémoire, et plus les accès seront rapides. Évidemment, si une application venait à avoir besoin de plus de mémoire, alors la taille du page cache serait réduite. Ce page cache est donc un élément critique des performances des entrées-sorties disques dans un système d'exploitation.

Jusqu'au noyau 2.5.3, le noyau utilisait une table de hachage globale pour le page cache, donc protégé des accès concurrents par un verrou global. Ce verrou global posait des problèmes de scalabilité sur les machines multi-processeur. Dans l'esprit de réduction du grain des verrous pour plus de scalabilité, cette table de hachage globale a été remplacée par un Radix Tree par fichier. Ainsi, les informations du page cache, au lieu d'être maintenues globalement, sont maintenues indépendamment pour chaque fichier. Le verrou est donc local, ce qui améliore la scalabilité, et la quantité de données à maintenir pour chaque fichier est moins importante, ce qui accélère les temps de parcours. Cependant, bien que cette solution soit nettement meilleure que l'ancienne table de hachage globale, les présentateurs ont identifié quelques problèmes, détaillées dans le papier.
Ils ont donc expérimenté d'autres structures de données:
L'orateur a ensuite présenté le résultat des expérimentations de ces différentes structures de données, via divers graphiques. Les résultats montrent que certaines structures de données se comportent mieux que le Radix Tree actuellement utilisée dans le noyau. Néanmoins, j'ai trouvé étrange que les tests soient réalisés sur des ensembles de 10 millions ou 100 millions d'éléments, alors qu'un page cache, surtout lorsqu'il est différent pour chaque fichier, comporte beaucoup moins d'éléments que ça. Un élément d'un page cache, c'est une page, soit 4 Ko de données. Si il y a 10 millions d'éléments, vous imaginez la quantité de données que ça représente. Du coup, comme les tests ont été réalisés sur un grand nombre d'éléments, les graphiques ne disent pas grand chose sur le comportement des structures de données pour un nombre d'éléments réaliste. Si ça se trouve, les différences entre les diverses structures de données sont mineures, voire même les résultats peuvent être inversés. J'avoue ne pas avoir saisi ces résultats, peut-être ai-je mal compris.

Pour aller encore plus loin dans l'amélioration des performances du page cache, une solution sans verrou (lockless) est présentée dans le papier. En effet, bien que le page cache au niveau de chaque fichier ai permis d'améliorer la scalabilité, ce n'est pas parfait : lorsqu'un fichier est très gros, le page cache de ce fichier est également très gros, et on se retrouve finalement avec les mêmes problèmes de scalabilité. La solution sans verrou détaillée dans le papier repose sur l'approche RCU, Read-Copy-Update. Une autre idée proposée est d'utiliser des gang-lookup. Je n'ai pas complètement saisi l'approche, mais il semblerait qu'elle consiste à verrouiller plusieurs pages sans les déverouiller, puis déverouiller ensuite tout d'un coup. Bref, pour plus de détails, voir le papier ;-)

Comme vous avez pu le constater, cette conférence était donc plutôt technique, mais néanmoins très intéressante.

TWIN: An Even Smaller Window System for Even Smaller Devices


Là aussi, je ne me suis pas rendu à cette http://www.linuxsymposium.org/2005/view_abstract.php?content_key=150 donnée par Keith Packard, mais Michael Opdenacker en a fait une http://free-electrons.com/torrent/ols2005-keith-packard-twin.ogg.torrent qui est peut-être intéressante à regarder.

Can you handle the pressure ? Making Linux bulletproof under load


Cette http://www.linuxsymposium.org/2005/view_abstract.php?content_key=170 traitait d'un sujet important : comment gérer la pression mémoire lorsque la machine est chargée.

Lorsque la machine fonctionne, le thread noyau kswapd essaie de conserver en permanence une certaine quantité de mémoire libre, et libérant éventuellement de la mémoire inutilisée. C'est ce qu'on appelle le background reclaim. Toutefois, lorsque la machine est vraiment chargée, et que kswapd n'a pas libéré assez de mémoire, il faut parfois libérer directement de la mémoire, c'est le direct reclaim.

Le but est de libérer les pages physiques les moins souvent utilisées dans le système, ce qui est possible grâce à des listes LRU (Least-Recently-Used) des pages du système. En réalité, il existe deux listes LRU: la liste des pages actives et la liste des pages inactives. Lorsqu'une page sort de la liste des pages actives, elle tombe dans la liste des pages inactives. Pour mettre à jour ces listes, le noyau regarde périodiquement si les pages ont été accédées ou non (cette information est donnée matériellement dans les entrées de table de page sous la forme d'un bit). Le papier explique en détail comment ces listes sont maintenues et comment les pages sont libérées grâce au mécanisme de reverse-mapping qui maintient la liste des correspondances physique vers virtuel de toutes les pages physiques.

Certaines structures de données, en particulier les slabs et les structures de données du noyau ne sont pas stockées dans des pages des listes LRUs. Certaines ne sont tout simplement pas libérables, d'autres le sont, mais grâce à des mécanismes particuliers.

Le papier détaille également le rôle des buffer heads, ces structures de données utilisées pour transférer des données entre le disque et la mémoire, et cacher ces données au sein du page cache. Néamoins ces buffer heads posent un certain nombre de problèmes : ils consomment de la mémoire dite basse (lowmem, en dessous de 820 Mo environ sur architecture x86 32 bits), et gardent une référence vers la page qui stocke les données, ce qui rend difficile sa libération.

Ils évoquent ensuite les pages qu'on ne peut pas libérer : certaines pages du noyau bien sûr (le code et les tables de page, notamment), mais également les pages bloquées par une application utilisateur par l'intermédiaire de l'appel système mlock(). En fait, les pages non libérables ne sont pas un problème en soi, le problème c'est qu'on ne peut pas les bouger pour satisfaire les allocations d'ordre important. Dans Linux, les allocations de pages physiques s'effectuent d'après un ordre : une allocation d'ordre 0 est une allocation d'une page, une allocation d'ordre 1 est une allocation de 2 pages, une allocation d'ordre 2 est une allocation de 4 pages, etc. (L'allocateur de pages physiques du noyau Linux est de type Buddy). Au fil de l'exécution du système, la mémoire physique se fragmente, et on peut avoir beaucoup de pages isolées permettant de répondre à des allocations d'ordre 0, mais plus de pages libres contigues pour répondre à des allocations d'ordre plus important. Il est donc important de pouvoir déplacer des pages physiques pour regrouper des pages libres contigues, et ainsi pouvoir servir des allocations d'ordre grand. Ainsi, le conférencier trouverait intéressant qu'on distingue dans le noyau le virtual pinning (les pages qui ne doivent pas changer d'adresse virtuelle) du physical pinning (les pages qui ne doivent pas changer d'adresse physique). Par exemple, les pages bloquées par un mlock() peuvent tout à fait bouger au niveau physique, c'est seulement du virtual pinning. En revanche, les pages utilisées pour réaliser des transferts DMA sont bloquées physiquement, c'est du physical pinning. Faire cette distinction permettrait de mieux savoir quelles pages on peut déplacer et quelles pages on ne peut pas déplacer.

Vient ensuite le problème des slabs. Ceux qui ne savent pas ce qu'est un allocateur par slab peuvent regarder le papier de Jeff Bonwick, c'est le papier de référence en la matière, et il est assez simple à comprendre. Cet allocateur est utilisé dans le noyau Linux pour allouer tous les “petits” objets (d'une taille inférieure à une page). Chaque page est découpée en éléments de taille identique qui pourront contenir des objets. Ainsi une page donnée ne contiendra que des objets de 16 octets, ou que des objets de 32 octets. Pour les objets très courants dans le noyau (inodes, dentry par exemple), il y a un cache associé. Toutes les pages d'un cache ne contiennent que des éléments de même type. Le problème, c'est qu'au fil des allocations et libérations, un cache peut contenir de nombreuses pages, mais beaucoup de ses pages ne sont pas pleines : les éléments sont dispersés un peu partout. Il semblerait alors utile de les regrouper pour mieux remplir certaines pages et en libérer d'autres. Le problème, c'est que cela implique de changer leur adresse virtuelle, ce qui est très difficile : il faut en effet modifier tous les pointeurs pointant vers les objets qui ont bougé. Cela est d'autant plus difficile que les objets utilisés dans le noyau possèdent beaucoup de références entre eux : ainsi chaque dentry pointe sur un inode. Si l'on change l'adresse virtuelle d'un inode (parce qu'on veut le regrouper avec d'autres dans une autre page), alors il faut modifier toutes les dentry qui pointent vers cet inode. Un exercice périlleux, qui d'une part nécessite d'avoir la liste de toutes les dentry dans un inode, et d'autre part, nécessite un mécanisme de verrou adapté pour faire tout ça d'un seul coup.
Une idée est d'associer à la création de chaque cache un callback spécifique appelé pour libérer des éléments du cache. Néanmoins, la plupart des éléments ne seront sûrement pas libérables facilement.

Avec toute cette fragmentation, le système peut refuser des allocations alors qu'il reste en fait plein de mémoire libre. Le problème est “simplement” que l'on arrive pas à récupérer cette mémoire libre. En résumé, une problématique très intéressante, mais également très complexe.
Pour en savoir plus sur le fonctionnement de la mémoire virtuelle de Linux, je vous recommande la lecture de l'ouvrage de Mel Gorman, Understanding the Linux Virtual Memory Manager, également disponible en version papier chez Prentice Hall.

Repas


Repas dans un restaurant plus ou moins irlandais du centre commercial. Je prends une salade, pour me remettre du fast-food du midi. Tout se passe plutôt bien, même si ça met du temps à arriver. Par contre, au moment de payer la note, là, c'est la grande question. La serveuse apporte la note, je pose ma carte bleue. Elle la prend avec la note, va au comptoir, et revient 5 minutes plus tard avec la carte bleue et un nouveau ticket. Sur le ticket est indiqué le total, et deux lignes vides : « Tip » et « Total ». On comprend rapidement que « Tip » c'est le service, qui n'est pas inclus au Canada. Par contre, avec mon collègue, on a du mal à comprendre comment ça peut marcher sachant que la serveuse m'a déjà rapporté ma carte bleue (en plus, je n'ai pas tapé mon code...). Comme deux stupides étrangers, on pose la question à la serveuse qui nous explique le principe. En fait, on ajoute la somme qu'on veut donner, on recalcule le total, et voilà. Ça suffit. En fait, en prenant la carte bleue, ils ont une autorisation de prélèvement, ils n'indiquent pas la somme tout de suite. Ils donneront la somme lorsque le client aura fait le total comprenant le service. Plutôt étrange ;-)

Soirée de bienvenue


La soirée de bienvenue était sponsored by Intel. D'ailleurs, le Symposium était massivement financé par des sponsors : Intel, AMD, IBM, Dell, EMC, HP, etc... Beaucoup plus commercial que les Rencontres Mondiales du Logiciel Libre, surtout quand on sait qu'IBM, Intel et AMD n'hésitent pas à déposer des brevets à la pelle.

Pour revenir à cette soirée, c'était organisé dans une gigantesque salle du centre de congrès, avec des dizaines et des dizaines de tables rondes pour accueillir le millier de participants. Des buffets à volonté, bar à vin et à bière également. Avec Michael et mon collègue, on trouve une table avec deux bonhommes de chez IBM et deux bonhommes de chez SGI. On échange un peu sur ce qu'on fait, mais c'est difficile vu le brouhaha ambiant qui complique la compréhension en anglais. Puis la présentation d'un gars d'Intel commence. Le vrai show marketing de base avec des slides magnifiques (contrairement aux slides vert sur noir, noir sur blanc faits avec MagicPoint des gens de la technique). L'orateur dit que Linux c'est génial, qu'à Intel ils en veulent, ils en mettent partout, tout ça en hurlant dans son micro comme un vendeur qui annonce les promotions sur la lessive dans un supermarché. Vraiment le truc marketing qui gave un peu tout le monde. Mais le bougre avait prévu le coup: pour s'assurer que tout le monde suit, il pose des questions au public, et il y a des cadeaux à la clé pour celui qui répond correctement. Ainsi, à la question « Combien de serveurs tournent sous Linux chez Intel ? », après de nombreuses tentatives par diverses personnes, quelqu'un trouve la réponse : « 52.000 ». Et hop, gagne un ordinateur portable. C'est pas beau le marketing ? Pour nous français, évidemment, difficile de répondre à ces questions ou même de suivre la présentation, le brouhaha couvre la voix suramplifié du bonhomme.

Le clou de la présentation, c'est la fin, l'ordinateur affiche
« Cet ordinateur a été vérouillé par Windows »
Évidemment, c'est le fou-rire dans le public. Le bonhomme vient de passer une demi-heure à nous dire que Linux c'est génial. Et paf, le portable est sous Windows. Même si on peut comprendre que Linux c'est surtout pour les serveurs (à son avis) et qu'il est peut-être obligé d'avoir Windows sur son portable pour diverses raisons, il faut avouer que c'est tout de même amusant.

Un cracheur de feu dans les rues d'Ottawa
Un cracheur de feu dans les rues d'Ottawa

Ensuite commence la deuxième présentation, intitulée « How to talk to business people about the value of Open Source ». Cet orateur, lui, tourne sous Linux. Mais les problèmes qu'il rencontre pour configurer son portable pour qu'il parle correctement au vidéo-projecteur sont peut-être l'explication de l'utilisation de Windows par l'orateur précédent ;-) Il essaie d'utiliser les assistants graphiques de cette distribution, apparemment une RedHat customisée IBM (puisque le monsieur travaille chez IBM). Après je ne sais combien de redémarrages du serveur X, il se résout à éditer le fichier /etc/X11/xorg.conf avec vi, sous les applaudissements de la salle ! ;-) La conférence en elle-même, c'est bien simple, je n'ai rien suivi, le gars avait un accent anglais incompréhensible, il ne parlait pas bien en face du micro et il y avait trop de bruit dans la salle. Pourtant le thème aurait pu être intéressant, mais au vu des slides, ça n'avait pas l'air si pertinent que ça. En plus, il faisait un froid de canard dans cette salle, car ils avaient poussé la climatisation à fond (une habitude chez eux, apparemment) et puis j'étais vraiment fatigué, à cause du décalage horaire (moins 6 heures par rapport à Paris). Donc je ne suis pas resté jusqu'au bout de cette merveilleuse présentation.

La première journée s'est donc terminée vers 23h environ, retour à l'hôtel. Lecture des mails avant d'aller dormir puisque l'hôtel dispose d'une connexion Internet gratuite. Un coup de DHCP, et paf, ça fonctionne. Magique, et en plus, la connexion est rapide. Que pouvait-on demander de mieux ?
Il n'y a pas de commentaire sur cette page. [Afficher commentaires/formulaire]