La sortie de la version stable 2.6.38 du noyau Linux vient d'être annoncée par Linus Torvalds. Le nouveau noyau est, comme d'habitude, téléchargeable sur les serveurs du site kernel.org.
Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche (qui est sous licence CC BY‑SA).
PS : Merci infiniment aux bonnes âmes qui ont participé à la rédaction collaborative de la dépêche et qui ont ainsi traduit les annonces de RC de Linus.
Sommaire
La phase de test
RC-1
La version RC-1 a été annoncée par Linus le 18 janvier :
« Cela fait deux semaines, la période de “merge” pour le 2.6.38 est donc fermée.
Et ça a été une période d'intégration intéressante.
Cette période de “merge” voit l'introduction de deux de mes fonctionnalités préférées :
l'utilisation de l'ordonnanceur de groupes pour permettre une meilleure interactivité lors de tâches UNIX “traditionnelles” (c-à-d un terminal avec une charge lourde comme un “make -j8” ou similaire) en donnant un groupe à chaque session tty (la variable de configuration “SCHED_AUTOGROUP”) ;
la nouvelle (enfin, “nouvelle”, c'est en préparation depuis longtemps) recherche de chemin basée sur le mécanisme RCU de Nick Piggin.
La fonction “autogroup” est vraiment plus un gadget technique qu'autre chose, mais il fonctionne vraiment bien pour le genre de choses pour lequel il a été conçu. Si vous faites encore un “véritable travail” dans un terminal, vous l'apprécierez très certainement. Compiler en parallèle dans une fenêtre, regarder un film dans une autre, et la vidéo est vraiment fluide. C'est vraiment palpable dans les faits. Ce n'est pas la panacée, mais c'est agréable.
La recherche de chemin basée sur le mécanisme RCU est à l'autre bout du spectre : l'anti-gadget absolu. C'est du bon travail sérieux qui se débarrasse du dernier gros verrou global qui avait réellement tendance à réduire certaines performances du noyau. Le verrou “dentry” n'est maintenant plus un gros problème de sérialisation. Ce qui est vraiment agréable, à ce propos, c'est que ça améliore aussi beaucoup les performances pour des tâches à simple thread (sur un noyau SMP), parce qu'on débarrasse d'une des parties les plus coûteuses de la recherche de composant du chemin, le “d_lock”, sur tous les composants de la recherche. J'ai pu constater des améliorations de 30 à 50 % sur certaines tâches intensives de recherche de chemin. »
RC-2
La version RC-2 est sortie le 21 janvier avec une perle de langage comme seul Linus sait les faire :
« Ça fait clairement moins d'une semaine, mais je pars pour la LCA
demain, donc j'ai voulu (a) sortir une -rc avant ça et (b) vérifier
que le portable que je vais prendre avec moi est complètement préparé
avec les bonnes clés de signature et tous mes scripts de release, etc..
Donc, si vous voyez quelque chose de bizarre dans la release, braillez,
car je peux encore, avec un peu de chance, corriger les problèmes de script/config que je suis susceptible d'avoir.
En tout cas, la -rc2 est sortie et le seul motif expliquant sa taille si raisonnable c'est que le délai de sortie a été court. Quelques requêtes d'intégration que j'ai eues sont quand même un peu plus invasives que ce que j'aurais souhaité avoir.
Je dois aussi vous prévenir que le portable que j'ai pris avec moi est pitoyablement lent. Je prévois de passer en mode “anal” et de n'intégrer aucune nouvelle branche, sauf si elles ont clairement vocation à faire partie d'une -rc. Autrement dit : n'essayez pas de me faire intégrer de gros patchs. Je ne les prendrai pas et ils peuvent attendre le 2.6.39 (ce n'est pas plus mal, nous avons déjà suffisamment de choses excitantes dans le 38).
Bien entendu, il est parfaitement possible que les choses restent calmes puisque de nombreux autres mainteneurs seront certainement aussi à la LCA ; donc, espérons que l'alerte “Linus passe en mode anal” était totalement superflue. »
RC-3
La version RC-3 a été annoncée le 1er février, soit 11 jours après la -rc2 en raison de la LCA (linux.conf.au) à Brisbane à laquelle Linus participait :
« À cause de la LCA, la -rc2 était disponible quelques jours en avance et,
pour équilibrer les choses, la -rc3 est en retard de quelques jours. Nous retournons maintenant vers un cycle hebdomadaire, puisque j'en aurai bientôt terminé avec mon voyage (je suis actuellement sur la route du retour - à l'aéroport de Cairns, fuyant le cyclone Yasi).
Rien d'extrêmement spécial dans cette -rc et je suis heureux de dire que la plupart des demandes d'intégration ont été de bonnes corrections de bogues et de régressions clairement identifiées. Merci à la plupart d'entre vous pour ça.
Maintenant récupérez-la et testez-la. Il semble que nous fassions de bonnes choses durant ce cycle de release. »
RC-4
La version RC-4 est sortie, comme prévu, le 7 février :
« Pas de voyage ou d'évitement de cyclone cette fois, donc comme promis, les -rc sont maintenant revenues à un cycle hebdomadaire normal.
Il n'y a rien qui ressort du lot ici. Quelques mises à jour d'archi (ARM et PowerPC), l'habituelle mise à jour des pilotes : DRI (radeon, i915), cartes réseau, son, média, iSCSI, quelques mises à jour de systèmes de fichiers (CIFS, Btrfs), et certains trucs, un peu partout, pour compléter le tout (réseau, “watchpoints”, “tracepoints”, etc.).
Assez petite, pour tout dire. J'aurais préféré évidemment qu'elle soit encore plus petite, et j'ai refusé dans cette -rc une ou deux requêtes d'intégration, mais pour une -rc4 ça n'a rien d'horrible. Tant que ça continue à diminuer, je suis content. »
RC-5
La version RC-5 est sortie le 15 février accompagnée par un message de Linus soulignant le faible nombre de modifications :
« Nouvelle semaine, nouvelle -rc.
Il n'y a pas grand chose à voir cette fois-ci : nous avons corrigé plusieurs régressions (y compris, j'espère, le bug que les développeurs d'Ubuntu ont rencontré et qui était causé par la nouvelle recherche de chemin via RCU) et d'autres choses relativement normales.
La plupart des changements sont courts et seuls les pilotes graphiques (pour Radeon et i915) sortent un peu du rang. Il y a aussi plusieurs déplacements de branches sur la documentation des périphériques qui peuvent paraître importants au regard des patchs habituels, mais ce sont juste des déplacements de fichiers hors du répertoire “powerpc” (puisque globalement la branche de développement sur les périphériques est devenue générique).
Globalement c'est une RC assez réduite.»
Ce que Linus ne précise pas dans son message accompagnant la RC-5, c'est que le faible nombre de patchs s'explique aussi par sa vigilance féroce. Il a l'habitude de scruter les patchs et il n'hésite jamais à hurler en cas de problème.
Prenez par exemple cet e-mail du 11 février dernier et qui concerne de menues corrections dans ext4:
« C'est un patch absolument dégoûtant et il provoque des tas de “warnings”. Ce n'est pas simplement un “oh, un warning !”. C'est plutôt un exemple de “oh, CE CODE EST UNE MERDE TOTALE !”.
Nom de Dieu, ne m'envoyez pas de la merde aussi tard dans le cycle. Clairement, il n'y a eu aucun contrôle qualité. »
Après un mea culpa contrit de Ted Ts'o le patch a finalement été corrigé.
RC-6
La version RC-6 est annoncée le 21 février par cette tirade de Linus au sujet de la clôture d'un bogue épineux :
« Hmm. Une nouvelle semaine, une nouvelle -rc. Celle-ci résout une corruption mémoire assez dérangeante (mais aussi très rare) avec laquelle nous nous battions depuis quelques semaines. Mais puisque je suspecte que seules deux personnes l'ont vu passer, je doute que la majorité d'entre vous en ait quelque chose à faire. C'était cependant un grand soulagement pour moi de voir ce bogue résolu ; je me permets donc de le mentionner. »
Par ailleurs, Linus précise qu'il n'y a pas beaucoup de gros changements à ce stade, ce qui semble le rassurer.
RC-7
La version RC-7 est sortie le 1er mars, accompagnée du commentaire de Linus :
« Il n'y a là pas grand chose à annoncer. Des mises à jour de pilotes (une ligne par‑ci par‑là, quelques mises à jour de codecs audio pour SoC et d'encore plus petites mises à jour du DRI) et quelques mises à jour de systèmes de fichiers (en particulier le FIEMAP de Btrfs et la gestion d'ENOSPC), mais vraiment toutes petites pour la plupart. Des régressions corrigées, en espérant qu'aucune n'aura été ajoutée. »
RC-8
Enfin, la version RC-8 a été annoncée par Linus le 8 mars :
« J'aurais pu sortir cette version comme le 2.6.38 final, mais je vais être absent quelques jours la semaine prochaine, j'ai pensé que ça n'avait pas beaucoup de sens d'ouvrir la fenêtre de merge maintenant.
En plus, nous avons des régressions. J'espère que quelques-unes sont résolues dans cette RC-8, mais ça ne fera pas de mal d'ajouter une semaine de test. »
Les nouveautés
Transparent Huge Pages
Le nouveau noyau 2.6.38 permet maintenant le support transparent des « huge pages », c'est-à-dire l'utilisation des pages mémoires de grandes tailles par opposition au pages traditionnelles de 4 Kio.
Les processeurs que nous utilisons tous les jours sont dotés d'une unité de gestion mémoire qui leur permet d'établir une correspondance entre les pages de la mémoire physique (RAM) et les pages de la mémoire virtuelle manipulée par le système. Cette table de correspondance, la page table, est hiérarchique avec plusieurs niveaux d'indirections à traverser avant d'obtenir l'information voulue. Pour éviter de perdre du temps à interroger cette table de correspondance et ses multiples niveaux d'indirections, on se sert d'une mémoire cache, le Translation Lookaside Buffer. Cette unité du processeur est importante pour les performances, et les constructeurs rivalisent d'imagination afin d'améliorer le TLB sur leurs puces.
Héritage de l'architecture x86, la taille typique des pages mémoire de la plupart des processeurs est de 4 Kio, ce qui est vraiment insuffisant avec les tailles mémoire des machines modernes.
Intuitivement, on voit bien que plus les pages mémoires sont petites et plus il faudra stocker d'informations dans la table de correspondance entre les pages physiques et les pages virtuelles. Évidemment, cela accroît la pression sur le TLB. Si j'ai un million de pages de 4 Kio, alors je dois « mapper » plus de choses que si je n'ai que quelques milliers de pages de 1 Mio. Dans le premier cas, j'ai de fortes chances de rencontrer un défaut de cache du TLB, alors que dans le second cas, les défauts de cache seront rares.
Encore plus important que la pression sur le TLB, les pages de 4 Kio obligent à traverser les multiples niveaux d'indirection de la « page table » alors que des pages plus grandes permettraient un accès quasi direct.
C'est donc pour résoudre ces deux problèmes que les « huge pages » ont été inventées. Au lieu de se contenter de pages physiques de 4 misérables kilo-octets qui induisent une forte pression sur le TLB et qui nécessitent de traverser de multiples niveaux d'indirections dans la table des pages (page table), on peut, depuis le Pentium Pro, opter pour des pages de 2 Mio ou de 4 Mio.
Pour les plus goulus d'entre vous, les machines x86-64 permettent même d'utiliser des huge pages de 1 Gio, tandis que l'architecture POWER va jusqu'à 16 Gio !
Certaines applications, en particulier les bases de données, profitent pleinement de ces huge pages et peuvent voir leurs performances augmenter de près de 10 %, comme c'est le cas avec Oracle ou DB2. Mel Gorman, dans sa magnifique série explicative sur les huge pages (1 - 2 - 3 - 4 - 5) indique même que certaines applications scientifiques enregistrent des gains de 45 % !
Tout va donc pour le mieux dans le meilleur des mondes et les huge pages sont disponibles pour ceux qui en ont besoin… Mais, il y a toutefois un petit problème. Certes, Linux supporte les huge pages depuis fort longtemps (2003) mais leur support est contraignant et difficile à configurer.
L'outil standard se nomme hugetlbfs et pour utiliser les huge pages il faut typiquement allouer un gros espace mémoire au boot et avoir des applications modifiées pour tirer parti de ce « réservoir » en passant par la fonction « get_huge_pages() »
. Ce n'est pas très pratique et cette difficulté d'utilisation a d'ailleurs été soulignée par Mel Gorman à la fin de sa série d'articles :
En dépit du fait que de nombreuses tailles de pages sont disponibles depuis plus d'une décennie, leur support sous Linux a historiquement été délicat à utiliser. Même les administrateurs systèmes doués évitaient de se lancer là-dedans.
L'idéal ce serait que Linux permette l'utilisation complètement transparente des huge pages quand il le peut. Au lieu de devoir modifier péniblement toutes les applications existantes et devoir réserver un gros tampon au démarrage de la machine, il faudrait que le noyau soit suffisamment malin pour utiliser les pages mémoires de grandes tailles automatiquement.
Coup de chance, c'est exactement le but du patch d'Andrea Arcangeli qui a été intégré dans ce noyau 2.6.38 !
Première étape du patch THP (Transparent Huge Page), il faut modifier le noyau pour lui permettre de gérer simultanément plusieurs tailles de pages. Alors qu'avant Linux présupposait que toutes ses pages avaient la même taille dans chaque région de l'espace d'adressage virtuel (les VMA pour Virtual Memory Area), il est maintenant possible de mixer des pages de 4 Kio avec des pages de 2 Mio.
Lors d'une allocation mémoire, et si un espace contigu suffisamment grand est trouvé, le noyau 2.6.38 pourra fusionner plusieurs petites pages dans une seule huge page (coalescing). En cas de nécessité de swap alors le noyau relâchera automatiquement la huge page qui se retransformera en une multitude de petites pages (splitting). Magique !
Pour augmenter les chances de pouvoir allouer des huge pages, il faut avoir ces fameux espaces mémoires non fragmentés disponibles au bon moment. Andrea a trouvé une solution ingénieuse, puisqu'un thread noyau spécifique, nommé « khugepaged », va s'occuper de ce travail en tâche de fond. Dès qu'il trouve un tel espace libre, alors il s'empresse de scanner la mémoire pour remplacer plusieurs petites pages de 4 Kio par une seule huge page.
Le patch actuel n'est pas encore tout à fait complet, puisqu'il ne permet d'exploiter que des huge pages d'une taille de 2 Mio. De plus, il ne fonctionne que sur les pages anonymes, c'est-à-dire celles obtenues à la suite d'un « malloc() »
.
En dépit de ces limitations provisoires, les tests ont montré que les performances étaient au rendez-vous. Un gain allant jusqu'à 10 % a été mesuré par Mel Gorman dans ce benchmark. C'est un peu moins bien qu'avec hugetlbfs, mais on gagne énormément en facilité d'utilisation, puisqu'il n'y a rien à faire pour en profiter.
On peut choisir d'activer cette nouvelle fonction en permanence et pour toutes les applications :
text
echo always >/sys/kernel/mm/transparent_hugepage/enabled
Mais il est également possible de n'activer les huge pages que pour certaines zones mémoires spécifiques indiquées par la fonction « madvise() » :
text
echo madvise >/sys/kernel/mm/transparent_hugepage/enabled
Une documentation complète est disponible, qui explique en détail tout le mécanisme du patch THP. Andrea Arcangeli a déjà indiqué qu'il allait continuer à travailler sur son patch, afin de gérer les pages de 4 Mio et 1 Gio, ainsi que la mémoire non-anonyme du cache de page.
Pour nous, simples utilisateurs, le code actuel présent dans le noyau 2.6.38 nous permet déjà de mieux exploiter les unités MMU de nos processeurs et d'augmenter les performances de nos applications.
Pathname lookup
Selon Linus Torvalds la plus importante nouveauté de ce noyau 2.6.38 est le patch de Nick Piggin qui optimise la fonction de résolution de chemin (pathname lookup) de la couche VFS.
Ce code est extrêmement complexe et Linus s'est même senti obligé d'envoyer un e-mail de mise en garde en plein milieu de la période de merge :
Je voudrais juste signaler le fait que j'ai intégré aujourd'hui le patch effrayant (mais très impressionnant) de Nick à propos du pathname lookup.
C'est effrayant parce que c'est du code qui est vraiment au cœur de l'OS, et parce que le nouveau modèle de lookup RCU est vraiment plus intelligent et subtil que le vieux spinlock dentry_lock.
Mais c'est aussi impressionnant et je voulais vraiment intégrer ce patch parce que ses résultats en termes de performance sont étonnants. Par exemple, une recherche de type« find . -size »
sur mon répertoire home (ce qui revient à faire des name lookups pour récupérer les stats sur chaque fichier récursivement) devient 35 % plus rapide. Et tout ça dans un contexte « non-threadé » !
Ici, on n'a pas un truc de montée en charge réservée aux machines haut de gamme, il ne s'agit pas de binaires recompilés qui profiteraient d'une nouvelle fonction. C'est juste que le pathname lookup est carrément plus rapide.
Même si la tâche n'est pas facile, essayons donc de décrire ce fameux patch que Linus lui-même trouve « scary ».
Tout d'abord un peu de contexte. Quand un processus en cours doit agir sur un fichier, ce qui arrive assez souvent dans un système UNIX, vous en conviendrez, alors il envoie le chemin (pathname) de ce fichier à la couche VFS pour qu'elle en gère l'accès.
Ainsi, chaque fois qu'est invoqué un appel système de type « open() »
, « read() »
ou encore « rename() »
, il faut donc utiliser le VFS pour retrouver l'inode du fichier sur lequel on va agir. En effet, c'est l'inode qui, en tant qu'identifiant unique du fichier, va indiquer les droits d'accès et plus généralement toutes les métadonnées associées.
Donc, le problème est clair : nous avons un chemin de fichier (pathname) et il nous faut trouver l'inode correspondant. C'est ce que l'on nomme le problème du « pathname lookup », c'est-à-dire la résolution du chemin.
Comment allons-nous procéder ? Et surtout, comment faire pour que ça aille vite ?
Le code du VFS effectue cette opération en séparant les différentes composantes du chemin. Après tout, quand on voit un chemin comme « /home/patrick/linuxfr/2.6.38.txt »
, on comprend bien qu'il est possible de le découper en morceaux séparés par « / », puisqu'il s'agit d'une suite hiérarchique de répertoires qui aboutit à un fichier unique.
On pourrait imaginer de parcourir le répertoire racine pour lire sur le disque tous les noms jusqu'à trouver le répertoire suivant, et recommencer ainsi de suite, jusqu'au fichier final. L'ennui, c'est que ce serait très long et qu'il vaut mieux stocker quelque part les relations hiérarchiques qui existent entre les répertoires, ainsi que les correspondances entre les inodes et les noms de fichiers.
La structure qui s'occupe de ça se nomme un « dentry » (pour directory entry) et, outre l'inode du répertoire, elle contient le nom du répertoire parent et les noms des répertoires enfants. Le dentry est donc la structure qui est utilisée pour faire la correspondance tant désirée entre le nom du fichier et son inode.
La fonction du VFS qui s'occupe de la tâche de résolution du chemin se nomme « path_lookup() »
et elle va utiliser le dentry pour faire son travail.
Cette fonction s'occupe, en outre, de tous les horribles petits détails techniques à considérer quand on veut arriver au but (la vérification des droits d'accès, le problème des liens symboliques et le risque associé de références circulaires, les points de montage, etc.).
On voit que la notion de dentry est très importante, centrale même, et qu'il faut pouvoir lire les informations contenues le plus vite possible, pour que la résolution du chemin soit la plus véloce possible.
Les dentry sont des structures de données contenues en mémoire et non sur le disque, ce qui permet un accès rapide. Le noyau maintient ainsi un cache de ces dentry (un cache de leurs empreintes) puisqu'il ne peut pas assurer la correspondance complète de la structure du système de fichiers dans la mémoire. Ce cache des dentry (le dcache) doit donc gérer les accès simultanés (on dit « concurrents ») des différents processeurs, et l'on voit bien que le contenu du cache va évoluer en permanence.
Chaque fois qu'une composante d'un chemin n'est pas présente dans le cache des dentry, il faut demander au système de fichiers d'envoyer les informations permettant de le créer. Il y a aussi le cas où le chemin contient une composante qui n'existe pas dans le système de fichiers. Là aussi, on stocke dans le dcache un « dentry négatif », pour éviter de perdre du temps à rechercher ce répertoire ou fichier inexistant lors d'une prochaine recherche.
Donc, si nous résumons ce que nous avons pour le moment :
pour résoudre les chemins, le noyau se base sur la notion de dentry ;
ce dentry fait la correspondance entre le nom du fichier qui est présent dans le chemin et l'inode du fichier ;
afin d'aller le plus vite possible, un cache des dentry est maintenu : le dcache ;
le dcache est sous la pression permanente des processeurs de la machine, et il faut optimiser son temps d'accès.
La solution simple et lente pour éviter les conflits sur le dcache est de poser un gros verrou dessus. Cela évite les problèmes du type retrait d'un dentry du cache par un processeur, alors qu'un autre processeur en a besoin au même moment. Ce gros verrou, le « dcache_lock », a été la première solution adoptée par Linux.
Depuis les noyaux de développements de la série 2.5.x, les codeurs du noyau ont remplacé dans certains cas le dcache_lock par un mécanisme optimisé. Pour s'assurer qu'un dentry utilisé ne sera pas retiré inopinément, on va poser un spinlock dessus, le d_lock, et l'on va incrémenter un compteur (refcount) le temps d'utiliser ce dentry. L'idée, c'est de ne verrouiller les dentry successifs des composantes du chemin que les uns après les autres, en séquence.
Cet algorithme, nommé « ref-walk », est, bien entendu, plus compliqué que le bon vieux verrou dcache_lock, mais il est aussi plus efficace, puisque le blocage est bien plus fin.
Comme souvent, quand un bond en performance est effectué, on découvre de nouveaux goulets d'étranglement qui étaient masqués par le code antérieur.
Un problème qui subsiste ici, est que l'utilisation permanente des compteurs (refcount) va souvent invalider le contenu de la mémoire cache des processeurs, et va donc limiter fortement les performances sur des machines multiprocesseurs.
C'est ici que commence le travail de Nick Piggin, puisqu'il incorpore un nouvel algorithme, nommé « RCU-walk », qui va permettre de faire sauter le goulet d'étranglement qui existait avec l'algorithme ref-walk. L'opération de « Read-Copy-Update », initiée par l'appel à « rcu_read_lock() »
, se fait maintenant sur la totalité du chemin, au lieu de s'effectuer sur chacun des composants du chemin. On fait le pari que tous les dentry seront présents dans le dcache, et ce pari est payant la plupart du temps. De cette manière l'opération d'incrémentation du compteur refcount ne se fait plus que sur le dentry final, au lieu d'avoir lieu sur les composants successifs du chemin parcouru.
Quand, par malheur, un dentry n'est pas présent dans le dcache, alors l'algorithme RCU-walk s'efface gracieusement et laisse opérer son prédécesseur ref-walk comme avant. Nick Piggin s'est aussi occupé du cas où un dentry est renommé par un processeur, alors que le chemin est parcouru. Le conflit est évité grâce à l'emploi d'un verrou spécial de type « seqlock ». Ce type de verrou ne bloque pas l'accès, mais permet de détecter qu'il y a eu un changement.
En (très) résumé, le travail de Nick a donc consisté à changer complètement la façon dont travaille le cache des dentry, afin d'optimiser ses performances. Il a également nettoyé tout le code de recherche de chemin d'accès (pathname lookup), en restreignant encore plus l'emploi du verrou dcache_lock qui était encore employé dans certaines zones. On retrouve également un verrou fin, le dcache_lru_lock, qui est posé sur la liste des dentry (LRU) et des changements sur l'interfaçage entre les systèmes de fichiers et le VFS.
On voit donc bien que cette série de patches est très complexe et touche de nombreuses zones de la couche VFS qui est au cœur du noyau. La promesse du travail de Nick Piggin c'est une amélioration des performances de montée en charge dans les opérations sur les fichiers. Par exemple, on peut imaginer que sur un gros serveur Web de nombreux processus tentent d'ouvrir des fichiers en même temps en se gênant les uns les autres. Dans ce cas de figure et dans bien d'autres, il est probable que le noyau 2.6.38 permettra d'améliorer sensiblement les performances.
Trusted keys
Le mécanisme « Trusted and encrypted keys », qui constitue une brique de base renforçant la sécurité et l'intégrité des systèmes GNU/Linux, a été intégré dans le noyau 2.6.38.
Le développeur Mimi Zohar de la firme IBM travaille depuis plusieurs années sur son patch EVM (Extended Verification Module) sans avoir pu le faire intégrer, jusqu'à présent, dans la branche principale du noyau. EVM est une protection cryptographique destinée à vérifier si une modification a eu lieu sur certains fichiers ou exécutables du système. Pour cela, une empreinte (un hash SHA-1) de ces fichiers est stocké dans les attributs étendus (xattr) du système de fichiers.
Linux possède déjà un mécanisme de vérification des fichiers et programmes qui a été intégré dans le noyau 2.6.30. Nommé IMA, pour Integrity Measurement Architecture, ce mécanisme ne permet une vérification efficace que contre les attaques en ligne (online attacks), puisqu'il effectue ses vérifications lors de l'ouverture des fichiers ou lors de l'exécution des programmes. Si un attaquant a un accès physique à la machine, alors il peut contourner la protection en démarrant sur un live-CD et en changeant les attributs étendus (offline attack) avant de redémarrer la machine.
Le mécanisme EVM, proposé par Mimi Zohar, a pour but de corriger cette faiblesse en générant une clé cryptographique qui va servir à signer les empreintes (hashes) des fichiers. Cette clé sera stockée dans le module de sécurité TPM (Trusted Platform Module) qui est un composant cryptographique matériel présent sur la carte mère de la machine.
Si un petit malin ayant accès à la machine s'amuse à la redémarrer après avoir changé les hashs présents dans les attributs étendus, il sera amèrement déçu. Lors du démarrage de la machine, la signature des hashs qui est présente dans le TPM sera vérifiée par la fonction « evm_verifyxattr() »
, et le résultat indiquera clairement que les hashs ont été modifiés et qu'une tentative d'entourloupe a eu lieu. En représailles, le noyau ne démarrera pas et le petit malin sera bien feinté.
Pour que tout ceci fonctionne bien et qu'aucune faiblesse ne subsiste dans cette gymnastique cryptographique, il faut être certain que la clé maîtresse d'EVM ne sera jamais accessible depuis l'espace utilisateur. Cette objection a été soulevée sur les listes de diffusion, et c'est en partie ce qui explique le blocage d'EVM pour l'intégration dans la branche principale.
Quand on veut faire intégrer un patch en « mainline », il ne sert à rien de se lancer dans des récriminations contre les opposants. Cela ne marche jamais, et il vaut mieux s'atteler à répondre à leurs objections techniques et à proposer des solutions. C'est ce qu'a fait Mimi Zohar en écrivant le patch « Trusted and encrypted keys » qui entre dans ce nouveau noyau 2.6.38.
Pour arriver au but à long terme qui est l'intégration d'EVM dans une prochaine version, il faut donc tout d'abord sécuriser les clés maîtresses. Le patch qui a été retenu ajoute deux nouvelles sortes de clés au trousseau de clés du noyau Linux. La première, la « trusted key », est générée par le TPM et elle est chiffrée avec la clé interne du module « storage root key » RSA 2048 bits, de façon à la protéger (sealing). L'accès à la clé (unsealing) ne se fait que si la configuration complète de la machine n'a pas été modifiée, c'est-à-dire si le BIOS, le chargeur et le système d'exploitation, sont conformes à ce qui a été enregistré au sein du TPM dans son « Platform Configuration Register ».
Bien entendu, une fois que la protection est déverrouillée par un utilisateur légitime, il est possible de changer le PCR pour mettre à jour sa machine.
La seconde sorte de clé, « encrypted key », ne repose pas sur les capacités du TPM, mais est tout simplement chiffrée avec l'algorithme AES présent dans le noyau, ce qui est plus rapide que d'utiliser le TPM et son mode de chiffrage asymétrique à clé publique. Cette encrypted key peut elle-même être chiffrée avec une clé maîtresse qui est souvent une clé de type « trusted ».
L'e-mail envoyé sur la liste de diffusion du noyau donne de nombreux détails au sujet de ces clés et explique comment les utiliser. Une documentation complète du mécanisme d'intégrité du noyau est également disponible.
Avec ces deux nouveaux types de clés protégées (activées par les options « CONFIG_TRUSTED_KEYS » et « CONFIG_ENCRYPTED_KEYS » lors du build), il est possible de tout garder en espace noyau et de ne faire passer aux applications qu'un « blob » complètement opaque (ASCII hexa) qui n'augmentera pas la surface d'attaque. C'est une garantie que le futur système EVM ne sera pas sensible aux éventuels problèmes et défaillances se trouvant en espace utilisateur, et c'est donc un pas de plus vers son inclusion.
Group scheduling
Le patch de group scheduling, qui a tant fait parler de lui à la fin de l'année dernière, a été intégré dans le noyau 2.6.38. Ce patch permet d'améliorer sensiblement l'interactivité dans certains cas particuliers, et il est très attendu par les utilisateurs ayant lu l'article de Phoronix qui a popularisé ce travail.
Depuis la dépèche LinuxFr de Victor en novembre dernier, le code de Mike Galbraith a été quelque peu modifié, mais l'idée générale est toujours la même.
Si l'ordonnanceur du noyau Linux se nomme CFS (Completely Fair Scheduler), c'est bien parce qu'il est vraiment équitable. Il divise strictement le temps de processeur disponible entre tous les processus qui s'exécutent sur la machine. Imaginons que vous lanciez une grosse compilation en mode « -j64 » (c'est-à-dire avec 64 jobs simultanés) et que vous ayez en plus un processus mplayer en train de s'exécuter, car vous regardez un film. L'ordonnanceur CFS va simplement diviser les ressources processeur en 65 morceaux, c'est-à-dire qu'il va choisir d'attribuer une tranche (slice) de temps processeur à mplayer, seulement une fois sur 65. Il y a fort à parier que mplayer ne va pas être content d'avoir si peu de ressources, et qu'avec cette méthode, l'interactivité de votre bureau Linux va souffrir.
L'idée de Mike Galbraith, qui, en fait, lui a été soufflée par Linus, consiste simplement à utiliser la notion de « cgroups » (Control Groups) pour isoler certains processus. De cette façon, l'ordonnanceur CFS affectera équitablement les ressources de calcul entre les cgroups et non pas directement entre les processus. Dans l'exemple évoqué ci-dessus, on aura un cgroup pour les 64 jobs de make et un autre cgroup pour mplayer. Les besoins de votre lecteur vidéo auront bien plus de chance d'être satisfaits, puisque, à chaque attribution d'une nouvelle slice, mplayer aura une chance sur deux d'être le gagnant.
Cela ne veut pas dire qu'il va s'attribuer en permanence 50 % des ressources et ne jamais les relâcher ; c'est juste que chaque fois que mplayer aura besoin d'avoir du temps processeur, il sera servi à égalité avec le cgroup des jobs lancés par make.
À l'origine, le code de regroupement des cgroups se faisait en fonction des « TTY », c'est-à-dire des terminaux virtuels. Depuis le code a évolué et il a été décidé de faire une ségrégation des cgroups en fonction de l'identifiant de session des processus. Ces sessions se lancent classiquement avec l'appel « setsid() »
et permettent de définir des groupes de processus. Par exemple, vous pouvez faire un petit « ps axgj »
sur votre machine et la colonne « SID » vous indiquera les groupes de sessions qui existent.
L'approche basée sur les TTY fonctionnait bien, mais elle semblait trop limitée puisque, pour la grande majorité des utilisateurs, ce sont les applications graphiques qui comptent et pas les terminaux virtuels. Avec le partage des ressources en fonction de l'ID de session, on a une solution un peu plus générale et donc potentiellement plus utile. Il faut quand même garder à l'esprit que cette nouvelle fonction, accessible via l'option « CONFIG_SCHED_AUTOGROUP », n'est que la configuration de base (et désactivée par défaut, qui plus est). Il est tout à fait possible, comme cela a été suggéré dans le monstro-thread de la LKML, d'effectuer une ségrégation des cgroups selon d'autres critères.
En dépit de toute la publicité qui lui a été accordée sur le web, ce patch de « group scheduling » avec le critère d'ID de session n'est pas d'une utilité transcendante pour les utilisateurs normaux. Certes, Linus aime beaucoup le patch, parce qu'il n'y a rien à configurer (it just works!) et parce que les gains sont réels pour son mode d'utilisation particulier. Ingo Molnar a lui aussi chanté les louanges de ce patch et l'a décrit comme étant :
L'une des plus importantes et des plus visibles améliorations de l'interactivité qui a été incluse dans l'ordonnanceur de Linux.
On peut là-aussi s'interroger sur ce qu'Ingo considère comme une utilisation « typique » de son système d'exploitation :
J'ai essayé quelques charges de travail typiques, comme faire un _build du kernel avec “make -j20” tout en lançant le test hackbench. L'interactivité de Firefox n'a pas été affectée de façon mesurable._
Lennart Poettering de son côté s'est empressé d'intervenir pour répondre à Linus et pour critiquer ce patch. Il propose une approche basée, vous vous en doutez, sur son nouveau démon d'init « systemd » :
Tout ça est complètement inutile pour les utilisateurs normaux. Le noyau porte ton nom, mais cela ne veut pas dire que ta propre utilisation soit typique ou qu'elle soit représentative pour plus qu'une poignée de _hackers comme toi.
J'ai juste préparé un patch pour systemd qui met tous les services et toutes les sessions utilisateur dans leurs propres cgroups. Si on active par défaut cette fonction dans systemd, alors cela voudra dire que les utilisateurs n'auront rien à configurer, parce que les distributions utilisant systemd auront ce comportement par défaut._
Il semble évident que pour généraliser complètement la fonction de « group scheduling » et pour la rendre vraiment utile aux utilisateurs classiques des interfaces graphiques modernes, il faudra en passer par la solution en espace utilisateur prônée par Lennart. En attendant, le noyau 2.6.38 permet déjà de bien s'amuser avec cette nouvelle fonction.
Infrastructure LIO
L'infrastructure de Target iSCSI LIO (Linux-Iscsi.Org) fait son entrée dans le noyau 2.6.38, après une longue compétition qui l'a opposée à son concurrent SCST.
Le protocole iSCSI (Internet Small Computer System Interface) est une norme officielle de l'IETF qui permet d'encapsuler des commandes SCSI pour les faire passer dans un réseau TCP/IP. De cette façon, on peut relier une machine cliente (nommée « initiator ») à un périphérique distant comme un disque SAN (nommé « target »). Cette norme iSCSI est intéressante à utiliser parce qu'elle est moins coûteuse à mettre en œuvre que le Fibre Channel et qu'elle réutilise les réseaux Ethernet classiques.
Dans la plupart des cas, on se sert du code iSCSI présent dans le noyau quand on a besoin d'accéder au disque distant. On agit donc en tant qu'initiateur, et le code qui permet de jouer le rôle de cible (target) ne nous concerne pas vraiment. Néanmoins, dans certaines configurations particulières, il peut être utile d'installer un système GNU/Linux qui jouera le rôle de cible, et le noyau permet aussi cette configuration grâce à l'infrastructure TGT (Linux SCSI target framework) et son option de configuration « CONFIG_SCSI_TGT ».
Cette solution TGT existe depuis des années, mais, vivant en grande partie en espace utilisateur, elle n'est pas sans poser quelques problèmes, notamment en termes de performances. Les développeurs de Linux étaient donc à la recherche d'un remplaçant crédible à intégrer dans le noyau, et ils ont évalué les deux projets les plus prometteurs.
Dans le coin droit du ring, le champion SCST (SCSI target subsystem for Linux) qui propose une multitude de fonctions complexes et un grand nombre de pilotes. Dans le coin gauche, LIO (Linux-Iscsi.Org) qui est plus simple et possède moins de fonctions, mais dont le code est considéré comme un peu plus « propre ».
La bataille a été âpre entre les deux compétiteurs, au point que l'article de LWN qualifie les discussions de « ugly », et les comparaisons plus ou moins biaisées n'ont pas manquées. La tension est d'autant plus grande que les enjeux économiques ne sont pas négligeables. Derrière ces deux solutions, il y a, certes, l'ego des développeurs, mais il y a aussi des entreprises qui voudraient bien que leur code entre dans la branche principale du noyau Linux. Pour SCST, on trouve le développeur Vladislav Bolkhovitin et la société ID7 qui finance les développements, tandis que dans le cas de LIO, c'est le développeur Nicholas Bellinger qui est employé par la société RisingTide Systems.
L'arbitre de cette dispute n'est autre que James Bottomley, le mainteneur du sous‑système SCSI dans le noyau Linux, qui s'est bien gardé d'entrer dans les querelles non techniques qui ont émaillées la saga du choix de la nouvelle infrastructure de Target iSCSI. Finalement, la situation a fini par se décanter au fil des mois et des sommets du noyau et, après une dernière passe de relecture et de nettoyage du code, James Bottomley a annoncé en décembre dernier que LIO allait intégrer la branche principale :
OK, je pense que nous avons atteint le point ou tout a été suffisamment rodé en dehors de la branche principale. Nous pourrons compléter les derniers items de la « todo list » directement sur le code intégré.
Même s'il manque encore quelques fonctions dans LIO qui arriveront plus tard, nous pouvons profiter dès maintenant de cette nouvelle infrastructure moderne de Target iSCSI (voir le graphique) :
- l'architecture est non-bloquante, complètement « multithreadée » et elle profite des unités vectorielles SIMD des processeurs ;
- fonction de « persistent reservations » pour faire de l'isolation (fencing) au cas où un nœud se met à avoir des problèmes ;
- mode d'accès ALUA (Asymmetric Logical Unit Assignment) pour choisir un chemin optimisé et performant vers les baies partagées sur le réseau de stockage ;
- multiplexage des connexions et répartition de charge (MCS) ;
- correction complète des erreurs (ERL0, ERL1 et ERL2) ;
- indépendance complète du média de stockage avec différents « backstores » adaptés.
Malheureusement, comme cela arrive parfois dans le monde très darwinien du développement de Linux, la décision technique prise par un mainteneur de sous‑système n'a pas été appréciée par les promoteurs de l'infrastructure concurrente. Le choix de LIO a fait réagir Vladislav Bolkhovitin qui a immédiatement crié au complot et demandé des explications :
Est-ce que quelqu'un peut expliquer quels sont les avantages de LIO par rapport à SCST ?
LIO est évidemment inférieur, que ce soit en termes techniques (voir la comparaison http://scst.sourceforge.net/comparison.html), ou en termes d'utilisateurs et de taille de la communauté. Les tentatives frénétiques pour essayer de lui donner meilleure allure par rapport à SCST n'ont rien changé. Dans les échanges récents, combien de gens ont voté pour LIO ? Personne. Combien ont voté pour SCST ? Un paquet. Est-ce que des vrais utilisateurs de LIO ont participé aux échanges ? Pas un seul.
Est-ce tout ça ne compte pas pour toi ? Que le code soit le meilleur ne signifie plus rien pour la communauté Linux ?
Ou alors, il y a des raisons secrètes ?
En dépit des accusations de Vladislav (« Undercover games » que j'ai traduit maladroitement mais sans trouver mieux par « raisons secrètes »), James Botomley a pris les choses calmement et a répondu point par point :
voir la comparaison
Pour être honnête, je me fiche des comparaisons point par point sur les fonctions respectives. Chacun des produits a des fonctions spécifiques de niche que l'autre n'a pas. Les fonctions de base sont disponibles dans les deux cas et sont solides.
combien de gens ont voté pour LIO ?
Ce n'est pas une démocratie. Il s'agit de choisir le projet qui est le plus réceptif aux besoins de la communauté et qui est le plus maintenable et facile à adapter. Ces six derniers mois LIO a fait des effors sincères pour répondre aux besoins des utilisateurs, pour nettoyer son code et pour s'adapter aux autres projets qui vont s'interfacer au‑dessus et autour de l'infrastructure. De l'autre côté, tu as passé ton temps à te disputer avec le mainteneur de _sysfs, en expliquant que c'était toi qui avait raison et lui tort._
Bien entendu, comme la personnalité de Vladislav le laissait soupçonner, le leader de SCST n'a pas été convaincu et a continué à protester bruyamment :
James, je suis désolé, mais ta position est absurde. En tant que mainteneur, tu es supposé choisir le code qui est DÉJÀ le meilleur, et pas celui qui promet de devenir le meilleur dans un futur indéterminé.
Pourquoi ne pas comparer toi‑même, au lieu de te reposer sur lesmensongesdéclarations de « NicholasB » et de ses supporters ? Dans la communauté du noyau, il n'y a qu'une seule personne qui soutient LIO, c'est Christoph Hellwig. Il est autoritaire et les gens n'osent pas le contredire. Mais son avis est aussi biaisé ; il y a plusieurs années, il a préféré TGT au lieu de choisir SCST qui existait déjà.
Évidemment, ces arguments assez paranoïaques n'ont fait que renforcer l'opinion de James Bottomley. Comme cela a été souligné plusieurs fois par Linus Torvalds et par d'autres mainteneurs, ce n'est pas seulement le code qui compte, mais surtout la capacité à travailler au sein de la communauté. C'est ce que lui a expliqué James Bottomley :
En tant que mainteneur, tu es supposé choisir le code qui est DÉJÀ le meilleur.
Exactement ! Tant que le choix s'oriente vers le projet qui est le plus orienté vers la communauté, alors les manques techniques seront comblés. Inversement, il est possible de détruire complètement un projet simplement en s'aliénant la communauté. C'est pour ça que la communauté est plus importante qu'une liste de fonctions supportées.
Des tonnes d'améliorations potentielles du noyau ont échoué à cause de problèmes avec le mainteneur.
Nous avons là une sorte de cas d'école pour analyser le mode de développement très spécifique de Linux.
Tout d'abord, comme le rappelle fermement James Botomley, il ne s'agit pas d'une démocratie ; les décisions des mainteneurs de sous‑systèmes et, en dernière analyse, les décisions de Linus, sont souveraines. Si un des gardiens du noyau vous indique qu'il faut modifier votre code pour qu'il soit accepté, alors il ne sert à rien de pester et de récriminer ; mieux vaut se retrousser les manches, car, en acceptant les remarques des autres, vous prouvez votre bonne volonté et votre intégration dans la communauté.
D'autre part, en acceptant les changements et en assurant la maintenance de votre ensemble de patches pendant des mois, vous donnez une indication que votre code ne sera pas abandonné à son sort après son intégration. Les mainteneurs de Linux ont encore en mémoire le système de fichiers Reiser3 qui a été complètement délaissé par Hans Reiser au profit du futur Reiser4. Ce cuisant souvenir explique le fait qu'ils exigent d'avoir l'assurance d'une maintenabilité correcte, et c'est un facteur très important dans leur choix d'une solution à long terme.
Enfin, cela va sans dire, mais cela ira mieux en le disant, les personnalités « difficiles » et « abrasives », comme Hans Reiser ou Vladislav Bolkhovitin, sont difficilement compatibles avec le mode de développement collaboratif du noyau Linux. Quand on voit des complots partout, quand on refuse d'entendre les critiques et qu'on se dispute en permanence avec tout le monde, il est fort improbable de voir son code intégré dans la branche principale.
En bref
Fitrim
À la fin de la section sur FITRIM dans la dépêche sur le noyau 2.6.37, il était précisé que cette fonction n'était activée que sur le système de fichiers Ext4. Rappelons que FITRIM permet d'informer le système de fichiers des pages qui ont été effacées sur un disque SSD, et cet effacement se fait en mode batch (batch discard) plutôt qu'à la volée pour le TRIM classique (on-the-fly TRIM).
Le nouveau noyau 2.6.38 permet maintenant de profiter des avantages de FITRIM sur les systèmes de fichiers Ext3 et XFS. Attention toutefois, car le lancement d'une passe globale FITRIM peut dégrader les performances et Christoph Hellwig conseille plutôt d'utiliser cette fonction en dehors des périodes d'utilisation normale de la machines (on peut configurer FITRIM au démarrage du sytème par exemple).
Transmit Packet Steering
Après le patch Receive Packet Steering qui était entré dans le noyau 2.6.35, voici maintenant que les hackers de Google ont réussi à faire intégrer leur nouveau patch Transmit Packet Steering.
La première fonction découpait le flot de paquets réseau entrant (receive queue) pour les affecter à des processeurs particuliers, tandis que la nouvelle fonction (patch XPS) fait exactement l'inverse. Elle part d'un CPU spécifique et elle lui affecte une queue de paquets réseaux sortants. Cette affectation se fait par le biais d'un masque CPU pour chaque queue qui est stockée dans « /sys/class/net/eth<n>/queues/tx-<n>/xps_cpus »
.
Cette association entre un processeur et une queue d'envoi de paquets permet d'améliorer la « localité » des données et donc de mieux profiter des caches de chacun des processeurs. Tom Herbert a procédé à de nombreux tests, et il a démontré un gain assez sensible d'environ 20 % apporté par ce patch de guidage de transmission des paquets (Transmit Packet Steering).
Test netperf TCP_RR avec carte de type bnx2x sur machine 16 cœurs AMD :
- sans le patch XPS : 996 000 transactions/s avec 100 % d'utilisation des CPU.
- avec le patch XPS : 1 234 000 transactions/s avec 100 % d'utilisation des CPU.
Améliorations de Btrfs
Le système de fichiers Btrfs, qui a vocation à remplacer la série classique des Ext2/3/4, propose de nombreuses fonctions fort sympathiques. Parmi celles-ci, il existe la possibilité de compresser les données à la volée de façon transparente avec l'algorithme « deflate » de la bibliothèque zlib. Le hacker Li Zefan, employé par la société Fujitsu, a écrit un patch qui permet d'utiliser également l'algorithme LZO avec Btrfs. Selon ses tests, ce nouvel algorithme est un peu moins efficace en termes de compression de données, mais il est, en contrepartie, beaucoup plus rapide. Comme nous sommes dans le cas d'une compression à la volée effectuée par le système de fichiers, cet argument de la rapidité est très important à prendre en compte.
Voici, par exemple, les résultats d'une extraction d'une archive tar des sources du noyau sur une partition Btrfs :
- Nocompress : extraction en 66,6 secondes pour une taille finale de 381,21 Mio ;
- Compression zlib : extraction en 94,4 secondes pour une taille finale de 132,36 Mio ;
- Compression LZO : extraction en 70,1 secondes pour une taille finale de 193,80 Mio.
Tracing
L'infrastructure de traçage du noyau continue d'être améliorée, version après version. Cette fois-ci, on trouve la possibilité, développée par notre ami Frédéric Weisbecker, d'utiliser les points de traçage sans être utilisateur privilégié. Cela s'effectue grâce à une macro « TRACE_EVENT_FLAGS() »
qui est appliquée aux points de traçage. Actuellement, il n'existe qu'une sorte de drapeau (TRACE_EVENT_FL_CAP_ANY
) qui est actif sur les appels système, mais d'autres sont envisageables.
Toujours en ce qui concerne le tracing, on trouve le patch d'Arjan van de Ven qui rend conditionnels les points de traçage. Alors qu'auparavant, un point de traçage était assez binaire (soit actif, soit inactif), il est maintenant possible de le faire travailler seulement si certaines conditions sont remplies. C'est un gros gain en termes de souplesse d'utilisation, mais l'objection qui vient immédiatement à l'esprit, c'est le coût en ressource de ces « IF » qui évaluent la condition. Pour éviter la surcharge (overhead), une nouvelle macro de définition des points de traçage a été créée. « TRACE_EVENT_CONDITION() »
s'ajoute ainsi à la macro « TRACE_EVENT() »
et elle permet de tester la condition sans que le point de traçage ne déclenche son mécanisme. Si la condition est remplie, alors le travail de traçage sera déclenché, mais si elle n'est pas remplie, ce sera comme si le point n'avait pas été activé du tout.
LZMA dans SquashFS
Le preux chevalier Phillip Lougher, qui avait essuyé un échec cinglant lors du cycle du noyau 2.6.34, a enfin pris sa revanche sur le dragon cracheur de feu.
Phillip avait essayé d'ajouter le support de l'algorithme de compression LZMA dans le système de fichiers SquashFS, mais son patch incorporait tout le code directement dans le header « unlzma_mm.h »
. Après le refus horrifié de Linus, la seule solution a été de se remettre au travail et de proposer un patch propre. Le noyau 2.6.38 accueille donc maintenant cette nouvelle possibilité de compression (algorithme XZ) qui est bien plus efficace que le classique gzip. Les développeurs de Fedora ont d'ores et déjà annoncé qu'ils allaient utiliser ce mode par défaut pour leur Live-CD Fedora 15. Une comparaison effectuée avec l'ancien système a montré un gain allant de 8 % (game spin) à 18 % (desktop spin), ce qui permettra de stocker plus de programmes dans l'espace limité du disque.
Sécurisation du noyau
L'effort de sécurisation renforcée du noyau continue avec cette version 2.6.38. Grâce au lobbying incessant de Kees Cook et de Dan Rosenberg plusieurs patchs, qui recouvrent souvent des fonctions présentes dans GRSecurity, ont trouvé leur chemin vers la branche principale.
On peut citer l'affichage des adresses mémoire du noyau qui est maintenant masqué par défaut. Alors qu'avant vous pouviez aller fureter librement dans /proc pour lire ces adresses mémoire, ce qui facilitait les tentatives de prise de contrôle, il vous faudra maintenant la (nouvelle) capacité CAP_SYSLOG pour y accéder. Cette fonction se paramètre via /proc/sys/kernel/kptr_restrict.
Le nouveau noyau propose également un travail d'amélioration de l'option CONFIG_DEBUG_RODATA effectué par Ingo Molnar. Cette option permet de marquer en Read Only certaines pages mémoires du noyau et, avec le noyau 2.6.38, nous bénéficions maintenant d'une protection contre l'exécution sur les données. Le bit NX (No eXecute) est mis pour les sections BSS (Block Started by Symbol) et un second patch protège le chargement des modules noyau en mettant le bit RO/NX sur les données et le bit RO+X sur le code.
Grâce à kptr_restrict, au renforcement de l'option CONFIG_DEBUG_RODATA et à l'ajout de l'option CONFIG_DEBUG_SET_MODULE_RONX le noyau Linux 2.6.38 sera mieux à même de résister aux exploits et les différences qui existent avec GRSecurity vont en se réduisant.
B.A.T.M.A.N
Le protocole de réseau B.A.T.M.A.N (Better Approach To Mobile Adhoc Networking) est un type de réseau ad hoc qui a été intégré à la branche -staging lors du cycle du noyau 2.6.33. Ces réseaux qui s'auto-organisent sont très à la mode en ce moment du fait des menaces qui pèsent sur le contrôle d'Internet dans des pays non démocratiques. Techniquement il n'est pas certain que ces réseaux ad hoc pourront "passer à l'échelle" mais B.A.T.M.A.N est certainement très intéressant sur un plan conceptuel et pour expérimenter des solutions innovantes.
Dans le noyau 2.6.38 ce protocole réseau a été considéré comme suffisament stable pour sortir de la branche -staging et intégrer la pile réseau de la branche principale. Une documentation complète est disponible pour permettre aux utilisateurs d'expérimenter les avantages et les inconvénients de ce type de réseau.
Sous-système NFC
Toujours dans le domaine des réseaux le pilote pn544 écrit par Nokia inaugure le nouveau répertoire drivers/nfc. Ce nouveau sous-système du noyau est destiné à accueillir les pilotes supportant la norme de communication NFC (Near Field Communication). De nombreux téléphones sont équipés de ces puces qui permettent d'échanger des informations à très courte distance par exemple pour effectuer des micro-paiements ou pour échanger des cartes de visites.
Bien entendu on ne peut que se réjouir de l'arrivée dans la branche principale de ce pilote libre pour le contrôleur NXP Semiconductors PN544 qui semble être la puce de référence choisie par Google pour ses smartphones Android.
Device-mapper
Une nouvelle interface permet au device-mapper (la couche qui est en charge de la gestion des volumes logiques) d'accéder au sous-système MD pour faire du RAID 4/5/6. La documentation écrite par Neil Brown explique comment utiliser cette nouvelle fonctionalité. D'autre part les performances de device mapper ont été améliorées par deux patchs de Mikulas Patocka (1 - 2) et les chiffres publiés sont très prometteurs.
Toujours en ce qui concerne le device-mapper on peut noter le patch d'Andi Kleen qui modifie dm-crypt pour permettre l'utilisation de multiples liste de tâches (workqueues). Auparavant il n'y avait qu'une seule workqueue de chiffrage/déchiffrage par mapping dm-crypt et cela constituait un goulet d'étranglement. Avec ce patch il y aura une workqueue par processeur pour permettre de travailler en parallèle et d'augmenter les débits.
Enfin, plus anecdotique, vous pouvez maintenant chiffrer les blocs de votre disque avec des clés différentes. Cette capacité "multi-clés" est utilisé pour permettre un mode spécial de compatibilité avec Loop-AES qui est un patch bien connu vivant en dehors de la branche principale du noyau.
AES-NI
En parlant de l'algorithme de chiffrage symétrique AES le noyau 2.6.38 propose une implémentation améliorée de la fonction AES-NI qui est présente dans les processeurs Intel récents et les futurs AMD Bulldozer.
AES-NI est une extension de l'architecture x86 qui ajoute sept nouvelles instructions permettant d'accélérer considérablement les opérations de chiffrage/déchiffrage de l'algorithme AES. Alors qu'auparavant le support n'existait que pour les x86-64 le nouveau noyau apporte maintenant la compatibilité avec l'architecture traditionnelle x86 32 bits. Evidemment, comme à chaque fois qu'on peut profiter d'une accélération matérielle, le gain en performances est énorme. Le développeur Mathias Krause a posté le résultat de ses tests dm-crypt effectués sur une machine Core i7 M620 tournant à 2.67GHz :
x86 | i586 | aes-ni | delta
------------|-----------|---------|----------
chiffrage ECB | 93.8 Mo/s | 123.3 Mo/s | +31.4%
chiffrage CBC | 84.8 Mo/s | 262.3 Mo/s | +209.3%
chiffrage LRW | 108.6 Mo/s | 222.1 Mo/s | +104.5%
chiffrage XTS | 105.0 Mo/s | 205.5 Mo/s | +95.7%
En plus de ce support des instructions AES-NI pour l'architecture x86-32 le code spécifique x86-64 a été optimisé et le débit des opérations de chiffrage/déchiffrage augmente un peu (voir le tableau des performances dans le message de commit).
Hole punching
Les systèmes de fichiers XFS et OCFS2 possédent une caractéristique intéressante puisqu'il permettent de désallouer un espace se trouvant au beau milieu d'un fichier déjà existant. Cette fonction porte le nom très imagé de "creuser un trou" dans le fichier (punching a hole). Cela parait franchement bizarre de vouloir faire ça mais c'est utile dans certaines configurations virtualisées. Par exemple si le système invité (guest) est alloué globalement sur un espace discontinu alors le fait de désallouer les zones non utilisées au sein du fichier permettra de récupérer facilement de l'espace.
Le développeur Josef Bacik, qui travaille pour Red Hat, a logiquement considéré qu'il n'était pas optimal de trouver cette fonction dans des systèmes de fichiers individuels. Pourquoi ne pas rendre le code plus générique afin que les autres systèmes puissent utiliser cette possibilité ? C'est le rôle du patch qu'il a proposé sur la LKML et qui a été accepté par Linus dans ce cycle 2.6.38. L'idée est simplement d'ajouter un mode FALLOC_FL_PUNCH_HOLE à l'appel système fallocate() qui sert déjà à manipuler l'espace disque des fichiers. Maintenant que cette option est disponible il est fort probable que les systèmes de fichiers Btrfs et Ext4 vont bientôt vous permettre de "creuser des trous" dans les fichiers !
Pilote graphique AMD
En ce qui concerne les cartes graphiques AMD, le noyau 2.6.38 permet la reconnaissance du coeur graphique présent dans les puces "Fusion" (en particulier le processeur Ontario). Du côté des cartes externes on trouve le support de la norme PCI-Express 2.0 dans le pilote Radeon et surtout l'arrivée du support 2D/3D des cartes Radeon "Northern Islands" (ce sont les cartes série 6000 portant les noms de code Barts, Turks et Caicos).
A partir de cette génération de cartes seul le fonctionnement via KMS (Kernel Mode Setting) sera possible et UMS (User-space Mode Setting) n'est plus utilisé. La carte Radeon HD 6970 (Cayman) qui est disponible depuis mi-décembre n'est pas encore supportée par le noyau Linux mais le travail est en cours et on peut s'attendre à la voir arriver dès le prochain cycle.
Nouveau
Le code de Nouveau, qui gère les cartes NVidia, a lui aussi été amélioré dans cette nouvelle version du noyau. On trouve le support des puces "Fermi" nvc0 (c'est à dire les GeForce 400/500). Le noyau 2.6.37 avait juste permis leut détection mais maintenant nous disposons d'une accélération 2D/3D avec un pilote mis à jour. Le point noir c'est que cette accélération dépend encore d'un firmware qui n'est pas présent dans les sources du noyau.
Pour les cartes un peu plus anciennes (c'est à dire la prolifique famille NV50) on trouve une amélioration du code d'allocation mémoire ainsi qu'une meilleure gestion de la mémoire vidéo.
Pilote graphique Intel
Dans le domaine des cartes Intel le noyau 2.6.38 apporte surtout des patchs permettant de mieux contenir la consommation et de gérer plus intelligement l'énergie. Jesse Barnes a indiqué que sur son laptop le patch de rafraichissement mémoire (actif sur les puces Ironlake et Sandybridge) lui permettait d'économiser 0.5W par rapport aux anciens noyaux. On trouve également l'intégration du mode d'économie en sommeil ultra-profond C6 et la possibilité d'overclocker automatiquement le coeur graphique Sandybridge en cas de faible activité du processeur. Enfin Keith Packard, bien connu du monde du développement X.org, est l'auteur d'un patch qui permet de détecter automatiquement les changements d'écran (automatic hotplug detection) sans avoir à lancer de coûteuses interrogations en permanence (polling).
Gestion des médias externes
Puisque nous parlons du polling il est bon d'évoquer le patch de Tejun Heo qui change la façon dont sont gérés les médias externes par le noyau Linux. Jusqu'à maintenant il n'y avait pas le choix et les applications en espace utilisateur devaient faire directment du polling pour savoir si un évènement était intervenu sur un périphérique (insertion ou éjection d'un disques optique ou d'une carte mémoire par exemple). Pour ça le périphérique en question était interrogé par la commande TEST_UNIT_READY mais cette façon de faire pose plusieurs problèmes.
Tout d'abord l'interrogation depuis l'espace utilisateur est une opération lourde et coûteuse et il y aurait avantage à faire le travail directement dans le noyau. Ensuite les pilotes Windows utilisent la commande GET_EVENT_STATUS et le firmware des disques tend a être testé uniquement pour cette commande ce qui pénalise Linux qui passe par TEST_UNIT_READY. Enfin le polling depuis l'espace utilisateur est une opération risquée puisqu'il n'y a pas vraiment de moyen de savoir si l'interrogation ne va pas provoquer un conflit. Tejun signale que le polling durant une session de gravage de données peut provoquer une erreur.
Pour résoudre tous ces problèmes d'un coup il a été décidé d'implémenter le polling des disques directement dans le noyau. L'avantage c'est que ce polling est bien plus léger (plus besoin d'ouvrir le périphérique) et surtout qu'on peut retarder une interrogation pour qu'elle coincide avec un autre évènement pour que le coût soit encore plus dilué.
Tous les pilotes vont devoir être changés et ils utiliseront désormais la fonction check_events() au lieu de la fonction media_changed(). Les "events" qui sont associés à cette nouvelle fonction sont au nombre de deux: DISK_EVENT_MEDIA_CHANGE et DISK_EVENT_EJECT_REQUEST. Il est possible d'indiquer la périodicité de polling en millisecondes dans "block.events_dfl_poll_msecs". Actuellement la valeur est positionné à zéro ce qui signifie que la fonction n'est pas active et que les applications userspace actuelles vont continuer à fonctionner comme avant. C'est maintenant aux développeurs de ces applications de profiter de cette nouvelle fonction pour nous permettre d'économiser des Watts sur nos machines.
V4L1 passe à la trappe
L'infrastructure de gestion V4L2 (Video4Linux seconde génération) est présente dans le noyau depuis la série des 2.5.x. Une émulation était jusqu'à présent proposée pour gérer les périphériques qui utilisaient encore la vieille interface V4L1.
Jugeant que la comédie avait assez duré il a été décidé qu'à partir du noyau 2.6.38 cette API d'émulation serait complètement retirée du noyau. Les applications V4L1 restantes devront soit passer par une bibliothèque en espace utilisateur pour les récalcitrantes, soit être convertie manu militari à l'API V4L2. Quelques pilotes V4L1 sans utilisateurs (cpia, stradis) ont été retirés du noyau 2.6.38. Les pilotes dépréciés ibmcam, konicawc et ultracam ont aussi été supprimés puisque ces derniers sont maintenant supportés par les pilotes GSPCA.
BKL
Le système de fichiers UDF (Universal Disk Format) est utilisé pour écrire des données sur divers média enregistrables de type DVD-R, CD-R, CD-RW, etc. Ce système de fichiers était l'un des derniers sous-systèmes assez importants du noyau à utiliser le verrou global (Big Kernel Lock) mais ce n'est plus le cas à partir de cette version 2.6.38. Un effort de nettoyage a été entrepris et Linus a accepté d'intégrer la branche UDF libérée du BKL.
Le développeur Arnd Bergmann a déjà annoncé son plan à long terme pour en finir complètement avec le BKL même dans les recoins les plus obscurs et poussiéreux du noyau Linux. Certaines sous-parties jugés inutiles seront envoyées vers -staging puis carrément supprimés à partir du noyau 2.6.41. On peut citer appletalk ou hpfs qui sont promis à la disparition à brève échéance. D'autres secteurs de Linux seront nettoyés au karcher de leurs appels intempestifs au verrou géant (Work around in an ugly way, but keep alive). C'est le cas des par exemple d'ufs, du pilote i810 ou encore d'IPX. Enfin un vrai travail de correction approfondi sera entrepris sur certaines parties qui le méritent (norme adfs ou protocole X.25).
Les ratés du noyau
Enfin un dernier point qui n'a pas spécifiquement de rapport avec le noyau 2.6.38. Je voudrais signaler la remarquable présentation de Jon Corbet (éditeur du site LWN) lors des dernières conférences Linux.conf.au et FOSDEM. Certes son accent est un peu difficile à comprendre mais les slides aident bien à la compréhension et puis ça vaut le coup puisque la vidéo est passionnante (lien vers la version FOSDEM). Au lieu de classiquement parler des réussites il a décidé d'évoquer les échecs, parfois retentissants, qui se sont produit lors du développement du noyau. Quels ont été les patchs rejetés, pourquoi ça n'a pas marché et surtout quelles leçons en tirer pour les développements futurs.
Hmm…finalement peut-être que cela à quand même un rapport avec le noyau 2.6.38 (cf la controverse LIO-SCST évoquée plus haut).
Dans cette conférence vous entendrez ainsi parler des systèmes de fichiers Tux3 et Reiser4, de l'ordonnanceur deadline de Con Kolivas et de l'infrastructure de tracing SystemTap. Un véritable cimetière des éléphants des patchs noyau et une mine d'or de bons conseils pour éviter les embûches !
Le bilan en chiffres
En matières de statistiques ce noyau 2.6.38 retrouve des niveaux de contributions typiques par rapport à la déferlante qu'avait été la version précédente. Comme d'habitude L'article de synthèse du site LWN permet de faire le point et on pourra également se reporter site remword dédié aux statistiques du noyau Linux pour trouver les chiffres de ce cycle.
En matière de patchs et de nombre de développeurs cette version est dans la moyenne avec l'intégration de 9 432 patchs écrits par 1 201 développeurs (chiffres du 10 mars).
Red Hat est toujours la première entreprise en terme de patchs avec plus de 11% des contributions (mais derrière la catégorie fourre-tout des "hobbyists" qui ne sont pas payés pour coder le noyau et qui fournissent plus de 15% des patchs). On trouve ensuite Intel, Novell et IBM qui sont des habitués du haut du tableau. Oracle est en douzième position avec 154 patchs et Canonical en vingt-deuxième position avec 101 patchs. Pour les curieux la liste complète des entreprises est disponible sur le site remword. On y trouve même, en cherchant bien en bas de la liste, des noms assez inattendus comme General Electric et Volkswagen ou encore des amis sincères du libre comme Apple et Sony.
Un chiffre toujours intéressant à regarder est celui des primo-contributeurs. Il s'agit des personnes postant un patch pour la toute première fois lors d'un cycle donné et ce depuis le 2.6.12-RC2 (date de l'import initial dans Git en avril 2005). Ces primo-contributeurs sont importants puisqu'ils représentent un apport de sang neuf dans l'écosystème du développement Linux. Bien entendu tous ne continueront pas à proposer des patchs mais certains d'entre eux deviendront sans doute des contributeurs réguliers du noyau.
Voici le tableau des primo-contributeurs sur les 10 derniers cycles:
Noyau 2.6.29 : 279 primo-contributeurs
Noyau 2.6.30 : 256 primo-contributeurs
Noyau 2.6.31 : 275 primo-contributeurs
Noyau 2.6.32 : 292 primo-contributeurs
Noyau 2.6.33 : 276 primo-contributeurs
Noyau 2.6.34 : 248 primo-contributeurs
Noyau 2.6.35 : 300 primo-contributeurs
Noyau 2.6.36 : 269 primo-contributeurs
Noyau 2.6.37 : 319 primo-contributeurs
Noyau 2.6.38 : 289 primo-contributeurs
Comme avec le nombre de patchs on voit que le cycle du 2.6.37 a été un peu exceptionnel avec pas moins de 319 primo-contributeurs. Le noyau 2.6.38 revient à des chiffres plus classiques mais toujours élévés. Très rares, pour ne pas dire inexistants, sont les projets libres qui voient arriver des patchs écrits par plus de 250 nouveaux venus tous les trois mois !
Aller plus loin
- Le bilan des ajouts partie 1 (1349 clics)
- Le bilan des ajouts partie 2 (781 clics)
# Preums \o/
Posté par Infernal Quack (site web personnel) . Évalué à -10.
C'était juste pour voir si on pouvait poster un commentaire avant la sortie officielle de la news.
L'association LinuxFr ne saurait être tenue responsable des propos légalement repréhensibles ou faisant allusion à l'évêque de Rome, au chef de l'Église catholique romaine ou au chef temporel de l'État du Vatican et se trouvant dans ce commentaire
[^] # Re: Preums \o/
Posté par ymorin . Évalué à -3.
Tricheur ! ;-)
Ceci dit, les commentaires sur les news en cours de rédaction peuvent être utiles pour valider, corriger, confirmer, orienter... la rédaction.
Du coup, ces commentaires devraient être masqués lors de la publication finale, avec possibilité de consulter l'historique (un peu à la façon de la page de commentaires de Wikipedia).
Sinon, je me réjouis par avance de lire la prochaine news de patrick_g sur le noyau ( C'est pour ça que je me suis caché les yeux ! Du coup, ça aide pas pour apporter des corrections... ;-) ).
Hop, hop, hop, m'en vais me coucher, moi... :-O
[^] # Re: Preums \o/
Posté par Zarmakuizz (site web personnel) . Évalué à -6.
Ah non, les mouleries de coulisse doivent rester six pieds sous terre !
Commentaire sous licence LPRAB - http://sam.zoy.org/lprab/
# Anal
Posté par Nucleos . Évalué à 9.
Je ne dirais pas «un tempérament anal», plutôt «un tempérament chiant», ou à la rigueur pointilleux, exigeant...
[^] # Re: Anal
Posté par Nucleos . Évalué à 0.
Et aussi "dis autrement" -> "dit autrement", "autrement dit"
[^] # Re: Anal
Posté par dj_ (site web personnel) . Évalué à 1.
et "Le noyau 2.6.37 avait juste permis leut détection "
[^] # Re: Anal
Posté par Faya . Évalué à 10.
À ce sujet, et sans vouloir faire mon oiseau de mauvais augure, Linus à l'air d'avoir une importance capitale dans l'organisation du développement du noyau. Que va-t-il se passer quand il ne sera plus là ? Est-ce que ça marchera aussi bien ? Y'en a qui sont près à reprendre le flambeau ? Est-ce qu'on ne va pas assister à une série de forks dus à tous ceux qui ne seront pas d'accord avec la nouvelle équipe "d'encadrement" ?
Je précise que je n'ai qu'une vague idée de l'organisation des développeurs du kernel donc peut-être que ma question n'a aucune pertinence et que le problème ne se posera pas ?
[^] # Re: Anal
Posté par Maclag . Évalué à 2.
Des gens capables, il y en a. Ce n'est pas le problème.
Au contraire, la situation idéale ce serait qu'il n'y ait qu'une seule personne capable et reconnue comme tel par tout le monde...
# Cgroup
Posté par barmic . Évalué à 3.
Ce noyau a fait beaucoup parler de lui à cause du fameu patch : https://linuxfr.org/news/patch-pour-le-noyau-linux-am%C3%A9liorant-linteractivit%C3%A9-entre-les-a
J'ai cru comprendre que le patch ne seras jamais intégré et il ne sers que de preuve de concepte. Je sais pas trop dans quel partie cela doit se mettre.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Cgroup
Posté par patrick_g (site web personnel) . Évalué à 10.
Bon j'essaye de gratter du temps partout ou je peux afin de rédiger les paragraphes sur les grosse nouveautés de ce noyau. Je sais pas si je vais tout pouvoir traiter mais les parties sur le pathname lookup et celle sur le patch transparent huge page sont déjà rédigées.
Je m'attaque au paragraphe sur le "fameux" patch du group scheduling.
# Lien vers les mails
Posté par barmic . Évalué à 3.
Pourquoi les liens pointent vers lwn ? Ce serais plus logique de les faire pointer vers la lkml directement non ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Lien vers les mails
Posté par patrick_g (site web personnel) . Évalué à 6.
Si tu parles des liens vers les annonces de RC oui tu as raison on peut les faire pointer vers la LKML.
# N'ayons pas peur des mots
Posté par UnixJunkie . Évalué à 10.
Je dirais même décap(it)antes!
--> [ ]
[^] # Re: N'ayons pas peur des mots
Posté par Anonyme . Évalué à 3.
Tiens, il y a eu une dépêche sur le sujet ? Je n'ai vu que des journaux.
# secu
Posté par M . Évalué à 6. Dernière modification le 15 mars 2011 à 14:32.
Ce n'est pas Ingo qui a fait le boulot.
En théorie il est mis pour tout ce qui n'est pas du code : bss, mais aussi les data, les section init (code et data)...
Mais sur le 2.6.38 ce n'est fait qu'en mode 32 bits. Un bug en mode 64 bits bloquait le suspend to RAM.
Un patch a été soumis, mais bon c'est pas un truc qui a l'air de passionner les devs Linux...
En fait c'est RO sur le code + données constante et X sur le code :
RO+X sur le code ;
RO+NX sur le données constantes ;
RW+NX sur les datas ;
[^] # Re: secu
Posté par Nicolas Boulay (site web personnel) . Évalué à 8.
Linus a beaucoup de mal avec les dev de sécurité. En général, ils sont des discours catastrophistes des personnes qui ne sont jamais écouté en espérant l'être en en faisant des tonnes. Ou alors, il s'écharpe sur le meilleurs système à avoir, cf les discussions entre le modèle de NSA linux et les autres, qui a finit avec un framework générique pour pluger des modules de sécurité.
J'ai l'impression, surtout après avoir vu la vidéo de J Corbet sur les ratés du noyau, qu'il faut clairement définir un objectif avec un problème à résoudre pour convaincre les dev linux, puis proposer une solution, sachant que l'important est de résoudre le problème et non d'avoir son code inclu.
"La première sécurité est la liberté"
[^] # Re: secu
Posté par Littleboy . Évalué à 4.
Mais bien sur. C'est surtout qu'il traite la secu comme la derniere roue du carosse.
Quand les commentaires de commit expliquant une faille potentielle sont "nettoyes" avant l'arrive dans son arbre git, que les infos sur des failles potentielles sont ignorees (ben oui, ca prend tu temps de trier, doh!), faut pas trop s'etonner si on n'est pas pris au serieux.
[^] # Re: secu
Posté par pasBill pasGates . Évalué à 7.
Ayant ete dans leur situation, je peux te dire que c'est pas aussi simple.
Le but d'un gars en securite c'est justement d'imaginer le pire scenario et s'assurer que ce n'est pas possible.
Le probleme souvent est que les devs, qui souvent n'en connaissent pas autant sur le sujet, trouvent que le gars securite exagere, que ce qu'il raconte n'est pas realiste, etc...
D'habitude les devs deviennent plus cooperatifs apres quelques exemples bien places, du moins chez nous c'est le cas, mais c'est un probleme qui est un peu le probleme de tout gars en securite : expliquer a un dev qu'il y a un bug, qui n'apparait que dans le cas ou X=Y et A=B et V=T, et qu'il faut le corriger parce que c'est super important, et c'est pas toujours facile.
[^] # Re: secu
Posté par Littleboy . Évalué à 9.
Ca depend, si tu t'appelles Ulrich Drepper (qui comme chacun sait est extremement ouvert aux critiques), rien ne t'arretes.
[^] # Re: secu
Posté par djano . Évalué à 7.
Il est super compétent, mais qu'elle espèce de [biiiiip] [bip] [biiiiip].
S'il arrêtait de prendre les gens de haut ce serait pas un luxe. Et s'il argumentait un peu ces décisions au lieu de dire "utilisez un kernel supporté" sans préciser quels kernel sont supportés ou encore "vous n’êtes pas mon employeur je ne vous dois rien", alors le monde du développement de la glibc se porterait beaucoup mieux.
Comment ça se fait que les autres membres de la glibc ne virent pas Ulrich Drepper à coup de tatanes bien placées? Ça me dépasse. Je me demande comment ils font pour bosser avec lui? Son comportement anti collaboratif ne cadre pas vraiment avec un logiciel libre aussi central.
Heureusement la eglibc existe et les mainteneurs ne sont pas aussi stupides qu'Ulrich Drepper et acceptent les patches.
[^] # Re: secu
Posté par Littleboy . Évalué à 9.
Il est mainteneur, avec tous les pouvoirs qui en decoulent (comme virer les droits de commits pour un autre developpeur sans explication...). Et jusqu'a septembre 2010, il etait paye par Redhat, ca aide pas mal.
Par ailleurs, il ecarte tres rapidement la majorite des volontaires qui voudraient participer (faut pas deconner, a moins d'etre paye personne ne veut bosser avec un type comme ca). Et se plaint qu'il est deborde de boulot. Et insulte les gens qui postent des patchs sur le bugtracker, en leur disant qu'il n'a pas le temps de s'occuper de ces conneries.
Enfin, depuis Octobre il bosse chez Goldman Sachs, ce qui je trouve est parfaitement approprie au personnage.
[^] # Re: secu
Posté par ecyrbe . Évalué à 5.
Ouais, heureusement que debian est passé à eglibc. Je pense que Bosser avec Ulrich Drepper doit être une galère de tous les instants. Je plains ses collaborateurs.
# Les amis sincères du libre
Posté par turanga leela . Évalué à 9.
"....des amis sincères du libre comme Apple et Sony".
J'aime beaucoup ton sarcasme!
# J'ai du mal à contenir mon impatience!
Posté par FantastIX . Évalué à 3.
J'ai hâte de voir cette branche pleine de bonnes surprises arriver dans Portage! Je n'attendais que ça pour mettre ma Gentoo à niveau et lancer une bonne grosse compil' de derrière les fagots, histoire de voir à quel point ce fameux patch de deux cents lignes est efficace...
Disons qu'avant je réduisais le niveau NICE du processus global emerge (si j'ai bonne mémoire et c'était il y a longtemps). Mais aujourd'hui, tout ça, c'est fini et le noyau régule tout automagiquement, tout seul, si j'ai bien compris. Je reviens dès que je serai passé à l'action. (Enfin, pas moi, le CPU de mon petit portable!)
» I'll be back!
Sur ce, je retourne à la lecture de la dépêche. Ne pas déranger, SVP!
[^] # Re: J'ai du mal à contenir mon impatience!
Posté par jujubickoille . Évalué à -1.
Tu peux --sync, mon miens est en train de compiler :]
[^] # Re: J'ai du mal à contenir mon impatience!
Posté par FantastIX . Évalué à 1.
Après avoir vu mon gestionnaire de fenêtre crasher (j'avais oublié de recompiler le pilote vidéo ATI car, oui, je suis, en plus, un heureux possesseur de Radeon 3670 :D ), je peux profiter du nouveau noyau. L'environnement graphique me semble un poil plus réactif voire plus rapide. Mais ce n'est peut-être qu'un effet placebo.
Ceci dit, j'avais le temps de lire les indications du splash Xfce (modèle Balou) à l'ouverture de ma session; maintenant c'est trop rapide. C'est ce qui me fait dire qu'il y a quand-même une amélioration des performances.
On verra ce que ça donne à l'usage mais je suis optimiste...
Pour info: - Intel Core2 Duo (T9400) - ATI/AMD Radeon Mobility HD 3670 - Pilote video xf86-video-ati-9999 version GIT (où y a pas de risque, y a pas de plaisir...)
[^] # Je confirme!
Posté par FantastIX . Évalué à 4.
Je viens de lancer sur mon portable une compil' de glibc et gcc avec -j16; c'est pas encore le score de Linus Torvalds mais à ce stade j'aurais déjà été bloqué et l'ordi aurait tellement ramé que je n'aurais pas pu poster ce commentaire avant la fin du processus. J'ai un film de test en arrière plan avec VLC, 16 jobs de make et je déplace la fenêtre de Firefox sur le bureau pendant ce temps. Rien. Aucun signe que le CPU et chargé, pire qu'un mulet — excepté celui du ventilateur, qui tourne à plein régime et fait un bruit de turbine (désolé, c'est de l'humour).
La glibc n'a pas pris plus de temps à compiler (environ une demi-heure). Et pendant que je rédige ces lignes, GCC est en cours de compil' depuis vingt minutes.
Y a pas, 2.6.38 pour Gentoo, c'est l'pied! :D
[^] # Je confirme!
Posté par FantastIX . Évalué à 0.
Je viens de lancer sur mon portable une compil' de glibc et gcc avec -j16; c'est pas encore le score de Linus Torvalds mais à ce stade j'aurais déjà été bloqué et l'ordi aurait tellement ramé que je n'aurais pas pu poster ce commentaire avant la fin du processus. J'ai un film de test en arrière plan avec VLC, 16 jobs de make et je déplace la fenêtre de Firefox sur le bureau pendant ce temps. Rien. Aucun signe que le CPU et chargé, pire qu'un mulet — excepté celui du ventilateur, qui tourne à plein régime et fait un bruit de turbine (désolé, c'est de l'humour).
La glibc n'a pas pris plus de temps à compiler (environ une demi-heure). Et pendant que je rédige ces lignes, GCC est en cours de compil' depuis vingt minutes.
Y a pas, 2.6.38 pour Gentoo, c'est l'pied! :D
EDIT: Le temps que je réfléchisse, et tout est terminé. Il a fallu une heure pour compiler GCC et GLIBC. C'est passé comme une lettre à la poste. Non, plus discrètement même.
[^] # Re: Je confirme!
Posté par sifu . Évalué à 2.
Question sans doute bête mais bon ...
Comment sont gérées les sessions ? Est-ce qu'il faut faire un setsid explicite ou est-ce que le fait par exemple de lancer une nouveau terminal (gnome-terminal par ex.) suffit à créer une session ?
Merci.
PS: J'ai qu'une machine sous Seven sous la main ...
[^] # Re: Je confirme!
Posté par FantastIX . Évalué à 1.
La sélection de l'option noyau AUTO_CGROUPS suffit. Aucune commande n'est nécessaire et la répartition du temps CPU est automatique, comme expliqué dans la dépêche.
# chic, du TPM
Posté par Gniarf . Évalué à 4.
ben merde alors je peux plus rooter mon joujou ?!? :-(((((
[^] # Re: chic, du TPM
Posté par Grunt . Évalué à 1.
Ouais, concrètement, TPM va rendre service à l'utilisateur ou au contraire l'emmerder?
Si ça va l'emmerder, pourquoi Linus a accepté d'inclure ça?
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: chic, du TPM
Posté par monde_de_merde . Évalué à 7.
Parce qu'il est pas responsable de l'utilisation qu'en feront les constructeurs ?
[^] # Re: chic, du TPM
Posté par Grunt . Évalué à -6.
T'es sérieux là?
Je veux dire: ça fait partie de la "politique" du noyau Linux que d'y ajouter des fonctions dont le seul but est de supprimer des fonctionnalités et de nuire à l'utilisateur?
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: chic, du TPM
Posté par Zenitram (site web personnel) . Évalué à 10.
FUD.
Tu devrais te renseigner sur les technologie dont tu parles avant de dire de bêtise dessus. Allez hop un tour sur en:Trusted_Platform_Module, tu constateras que la fonctionnalité dont tu parles (les DRM donc si j'ai bien compris) est dans la partie "Other uses". TPM a d'autres buts, et ne nuit pas du tout à l'utilisateur (Platform Integrity, Disk encryption, Password Protection, c'est peut-être pas utile pour toi, ça l'est pour d'autres).
[^] # Re: chic, du TPM
Posté par Nicolas Boulay (site web personnel) . Évalué à 10.
La seul question qui se pose est : qui contrôle la clef du cadenas ?
Si c'est un tier, c'est un DRM, si c'est toi-même, le problème ne se pose pas.
"La première sécurité est la liberté"
[^] # Re: chic, du TPM
Posté par briaeros007 . Évalué à 5.
ce n'est malheureusement pas la seule question.
La deuxieme question est "qui peut copier la clé du cadenas".
Et les normes TPM disent très clairement que le fabricant peut les copier...
[^] # Re: chic, du TPM
Posté par briaeros007 . Évalué à 2.
il y a un proverbe pour ça, c'est "laisser entrer le loup dans la bergerie".
Tu fais ce que tu veux après, hein.
Moi j'adorerais un coprocesseur cryptographique, mais j'ai aucune envie de voir tpm.
[^] # Re: chic, du TPM
Posté par neerd . Évalué à 9.
Pour moi TPM est un outil qui peut servir à bien des choses, ton analogie est équivalente à celle qui consiste à dire qu'internet sert juste à pirater des contenus sous copyright.
[^] # Re: chic, du TPM
Posté par dab . Évalué à -1.
Mouais. Enfin, si tu sais que l'utilisation ne peut être que mauvaise, tu en tiens compte.
# Hein ???
Posté par barmic . Évalué à 2.
J'y comprends rien, kernel.org propose toujours le 2.6.37.4, il y a une erreure de manip' ou DLFP est plus à jour que kernel.org ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Hein ???
Posté par BAud (site web personnel) . Évalué à 4.
Explication : Linus Torvald sur la LKML ainsi que patrick_g (et les co-rédacteurs) sur LinuxFr sont en avance sur kernel.org ;-)
Tu noteras tout de même que le 2.6.38 est actuellement proposé en mainline juste en dessous du 2.6.38-rc8-git5 sur http://kernel.org :p
# Transparent huge pages
Posté par Quzqo . Évalué à 4.
Merci pour cette dépêche qui me rend encore moins productif (si faire se peut..)
Juste une question concernant les huge pages : pourquoi ne pas avoir l'approche inverse à savoir allouer par défaut des huge pages et les fragmenter si besoin ? Ce ne serait pas plus simple pour garantir la disponibilité d'espaces d'allocation contigus, à priori ?
[^] # Re: Transparent huge pages
Posté par ecyrbe . Évalué à 3.
Je dirais, parce que toutes les architectures n'ont pas de mécanisme de huge page et qu'utiliser des huge pages pour des petits processus on peut considérer ça comme du gachi.
Il vaut donc mieux utiliser par défaut le plus petit dénominateur commun et utiliser des pages plus grosses si le processus se met à utiliser plus de mémoire et que le mécanisme est fournit par l'architecture.
[^] # Re: Transparent huge pages
Posté par Brice Goglin . Évalué à 2.
Allouer une hugepage dès qu'un processus demande une allocation d'un octet, ca serait du gachi (encore plus du gachi que d'allouer 4ko comme on le fait actuellement).
[^] # Re: Transparent huge pages
Posté par beagf (site web personnel) . Évalué à 3.
Sauf qu'un processus ne demande jamais un octet au système. Un processus demande des blocs à son gestionnaire de mémoire qui lui va faire des demandes au système s'il n'a pas de blocs de libre, et de base il va demander des blocs relativement gros.
Quand ton processus écris ensuite dans une zone pour la première fois le système va alloué une page sans savoir la taille du bloc que le programme compte utiliser.
Le truc c'est que tels que sont foutus la majorité des allocateurs mémoire, il est raisonnable de dire que la mémoire perdue par processus est au plus égale à la taille d'une page moins quelques octets et en moyenne égale à une demi-page. Et vu que des processus il n'y en as pas une tétra-chiée et que l'on peu toujours spliter la page en cas de besoin urgent, je pense aussi que par défaut ce serait pas plus mal d'allouer des grosse pages. (je parle de page de 2mo pas des pages de 1go…)
[^] # Re: Transparent huge pages
Posté par Gniarf . Évalué à 3.
tu pensais à PHP et autres gloutonnosaures ?
[^] # Re: Transparent huge pages
Posté par Brice Goglin . Évalué à 2.
Je pensais juste à la théorie générale du bidule: les applis demandent des quantités quelconque de mémoire, et le système utilisant la pagination doit allouer des pages entières pour les satisfaire. Plus la taille des pages est grande, plus il y a de fragmentation interne, et possiblement du gachi.
[^] # Re: Transparent huge pages
Posté par Brice Goglin . Évalué à 1.
Et malloc(1) alors... Tu fais alignes toujours tes mallocs sur la taille des pages toi ?
Ton processus n'a pas besoin de savoir comment est gérée la mémoire, si elle est paginée ou pas. C'est le noyau (et la libc) qui se débrouillent.
Et même si on considère que le processus finit par demander 4ko au noyau via la libc, l'argument reste valable: pourquoi allouer une hugepage entière si le processus ne veut que 4ko. Gachi idem.
[^] # Re: Transparent huge pages
Posté par barmic . Évalué à 1.
Si je ne m'abuse ce n'est pas malloc qui va gérer l'allocation des pages, mais brk. malloc n'est pas un appel système.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Transparent huge pages
Posté par Brice Goglin . Évalué à 1.
Le système n'est pas le noyau, hein (Linux != GNU/Linux). malloc est dans la libc, les processus utilisent la libc... (btw, malloc utilise souvent mmap au lieu de brk)
[^] # Re: Transparent huge pages
Posté par barmic . Évalué à 1.
Et alors ? Je dis juste que malloc ne touche pas au pages mémoire donc que la manière de l'utiliser n'influe pas directement sur la manière dont le noyau va gérer les page mémoire.
Si tu me branche parce que j'ai dis que malloc n'est pas un appel système, peut être qu'il faudrait que tu revois la définition d'un appel système.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Transparent huge pages
Posté par Brice Goglin . Évalué à 2.
Euh, j'ai jamais joué sur les mots "système", ou "appel système" ou pas moi hein, j'ai juste dit "... dès qu'un processus demande une allocation d'un octet..." au départ. Fallait juste pas que vous lisiez "appel système" là dedans. Si vous interprétez tout n'importe comment, faut pas vous étonner de lancer un troll...
[^] # Re: Transparent huge pages
Posté par barmic . Évalué à 1.
Pour terminer, je réagissais à ça :
Quand tu fais un
malloc(1)
, la libc va probablement allouer plus d'un octet au processus, donc le noyau n'a pas moyen de savoir si tu utilise un seul octet. C'est tout.Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Transparent huge pages
Posté par Brice Goglin . Évalué à 1.
Exactement, et il n'a pas non plus moyen de savoir si allouer une huge page est une bonne idée ici ou non, donc il ne le fait pas car gachi. Par contre, si on lui demande 1Go, là il sait que c'est surement une bonne idée de prendre une huge-page.
[^] # Re: Transparent huge pages
Posté par beagf (site web personnel) . Évalué à 3.
J'étais parti pour faire une longue explication sur pourquoi ce ne serais pas stupide vu le fonctionnement des gestionnaires de mémoire mais en fait il y a beaucoup plus simple :
De manière générale, la mémoire « gaspillée » est au plus égale à la taille d'une page moins un octet et en général elle est aux alentours d'une demie page. Sur mon système qui n'a rien de particulier — les programmes classiques avec un desktop, un lecteur de mail, un navigateur et quelques terminaux et éditeurs — j'ai 71 processus en cours.
Cela veut dire qu'avec des pages de 2Mo je « perd » environs 71Mo. Mais ils ne sont absolument pas perdus, c'est juste des pages qui doivent être fragmentées si il n'y a plus de mémoire.
Et au final j'aimerais même pouvoir désactiver cette fragmentation automatique car je préfère qu'il envoi dans le swap une page de 2Mo plutôt que de la fragmenter. Il faut bien voir qu'il y a d'autres intérêts au grosses page que la libération de la TLB, il y a aussi le fait qu'une application sait que toutes les données au sein d'une page sont contiguës en mémoire. Et la localité en mémoire est très importante pour avoir des latences faible dans les accès séquentiels et pour optimiser les caches.
Donc voilà, moi j'aimerais beaucoup pouvoir compiler mon noyau sans gestion des pages de 4ko. Tu fais comme tu veux avec le tien.
[^] # Re: Transparent huge pages
Posté par beagf (site web personnel) . Évalué à 2.
Petite correction à un post posté un peu trop vite… C'est plutôt deux demie-pages qui peuvent-être « perdues » (où fragmentées) une pour la zone de pile et une pou la zone de tas. Et pour les zones de code et de données statiques les pages de 4ko restent utiles puisque la taille de ces zones ne change généralement pas.
[^] # Re: Transparent huge pages
Posté par kernelloulou . Évalué à 1.
Si tu veux un système sans pages de 4ko, tout l'argument de faire de la fragmentation quand il n'y a plus de mémoire perd son sens. En plus d'une demi page pour la pile et du tas, tu auras une demi page pour chaque binaire chargé et chacune des libs utilisées. Et probablement aussi plein de pertes dans les allocations mémoires du noyau. Ca va rapidement faire des centaines de demi-pages. La RAM ne coute pas cher mais c'est du gros gachi et on a toujours aucune preuve que ca sera utile au final.
Tes arguments sur la localité mémoire s'appliquent aux données manipulées par les codes parallèles, pas au code lui-même, et encore moins aux données et code qui tournent sur ton desktop (vu que ces accès ne sont pas optimisés en pensant à la localité).
Ca fait des années que les hugepages existent et personne n'a demandé une telle config dans le noyau, il doit y avoir une raison... Peut-être parce qu'il y a des gens qui ont fait des vrais études et mesures et constaté que ca ne changeait pas grand chose aux perfs.
[^] # Re: Transparent huge pages
Posté par beagf (site web personnel) . Évalué à 3.
J'ai corrigé dans mon deuxième commentaire le fait que les small pages gardent un intérêt.
Pour ce qui est de la localité, c'est en effet très utile pour les codes parallèles mais ça l'est aussi pour tous les autres codes. Que tes accès soient optimisés ou pas, tu va augmenter la localité avec des pages plus grosses. Il y a eu plusieurs article sur le fait que généralement des données allouées avec un faible intervalle de temps serons utilisées avec un très faible intervalle de temps. Plus tes pages sont grosses, plus tu as de chance que ces données soient dans la même page et donc proche en mémoire.
C'est sûr qu'optimiser réellement sont code pour la localité fait gagner mais le comportement de base de beaucoup de structures de données permet d'obtenir un minimum de localité si le reste est bien géré.
Et l'argument de la localité ne s'applique pas qu'au données comme tu le dis mais aussi au code, la majorité des compilateurs optimise même la position des fonctions dans le binaire afin que les fonctions qui s'appellent entre elles soient proches. Le cache de niveau 2 est partagé avec les données ce qui demande de la localité, le cache de niveau 1 est séparé mais demande aussi de la localité.
C'est surtout que ça fait des années qu'utiliser des hugepage est une galère monstrueuse et que donc les gens restent sur les petites…
Mais surtout je ne veux pas l'imposer à tout le monde mais avoir le choix.
[^] # Re: Transparent huge pages
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Attention tout de même à ne pas tout mélanger. Tu as l'air de dire que la localité d'accès augmente, si on utilise une grosse page de 2Mo à la place n pages de 4ko pas forcément contigüe.
Les mémoires caches fonctionnent avec des lignes de 32 à 128 octets. Lorsque l'on parles de localité, on parle de ces lignes là. Pour aller plus loin, il faudrait que les patterns d'accès rendre insuffisant le nombre de "voies" des caches. Les pages de base faisant 4ko, le problème ne se pose pas vraiment.
L'intérêt est vraiment dans la diminution du nombre de défaut de page. Un cpu doit gérer en interne ~1000 pages soit quelques Mo de mémoire adressable sans interruption. Un défaut de page peut couter qq centaines de cycles. Donc un accès purement aléatoires sur 1 Go de ram peut entrainer un taux de défaut de page très important, d'où l'importance des hudge page.
"La première sécurité est la liberté"
[^] # Re: Transparent huge pages
Posté par beagf (site web personnel) . Évalué à 4.
La localité ce n'est pas que pour optimiser l'utilisation du cache, c'est aussi pour profiter au maximum du prefetch. Lorsque tu accèdes à une zone mémoire de manière continue les données arrivent en flux car il n'attend pas le read pour charger les données dans le L2. Si tes données son réparties sur plein de petites pages, ça ne marche plus.
De la même manière, tu as le prefetch au niveau du disque dur, il vaut mieux récupérer 2Mo de données contiguës d'un coup que plein de morceaux de 4Ko répartis un peu partout.
[^] # Re: Transparent huge pages
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Le prefetch ne dépassent pas les limites de pages justement pour éviter les pages miss et les pages fault. Cela m'étonnerait que les cpu actuelles puissent allez au dela de la limite de 4ko, car pour cela il devrait avoir l'information du type de page actuel.
De plus, les prefetchs sont petits, il s'agit de lire 1 ligne ou 2 de cache en avance.
Le problème du swap est différent. Tout est plus rapide qu'un accès disque, donc on peut se permettre des algo très intelligent.
"La première sécurité est la liberté"
[^] # Re: Transparent huge pages
Posté par beagf (site web personnel) . Évalué à 2.
Relis mon commentaire et tu verra que c'est ce que je dis… Avec une grosse page tu profite bien plus du prefetch qu'avec une petite.
Bien sûr, si tu accèdes à l'adresse x, il va prefetcher x+1, mais quand tu vas utiliser x+1, il va prefetcher x+2. (x étant une ligne de cache)
Donc au final si tu fais un accès continus le prefetch est actif en permanence et si ton traitement sur x n'est pas trop court, les latences mémoires sont masquées.
Ce n'est pas une question d'algos intelligents ou pas, c'est juste que lorsque tu récupère des données depuis le swap ou depuis un fichier, pour ce qui est du temps de transfert que ce soit 4k ou 2Mo la différence est minime, ce qui compte c'est la latence qui est la même et bien supérieur au temps de transfert. Donc autant récupérer directement 2Mo (voir plus) et surtout stocker ce gros bloc dans une seule grosse page pour pouvoir profiter du prefetch ensuite et réduire les pages miss et cache miss.
[^] # Re: Transparent huge pages
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Relis mon commentaire et tu verra que c'est ce que je dis… Avec une grosse page tu profite bien plus du prefetch qu'avec une petite.
Relis mon commentaire, le système de prefetch devrait connaitre le type de page pour pouvoir franchir la barrière des 4 ko lors d'utilisation de page de 2 Mo, ce dont je doute fortement.
Bien sûr, si tu accèdes à l'adresse x, il va prefetcher x+1, mais quand tu vas utiliser x+1, il va prefetcher x+2. (x étant une ligne de cache)
Pour une lecture continue sur 2 Mo, en petite page, tu fais sauter un prefecth sur 32, soit 3% des accès. C'est pas énorme.
"La première sécurité est la liberté"
[^] # Re: Transparent huge pages
Posté par Antoine . Évalué à 1.
Si le système de prefetch opère sur des adresses virtuelles, il doit bien utiliser la TLB pour accéder à la mémoire, donc il sait quel type de page il est en train de préfetcher.
[^] # Re: Transparent huge pages
Posté par Brice Goglin . Évalué à 4.
Une galère sous Linux oui. Mais d'autres systèmes ont une gestion intéressante depuis longtemps (IRIX iirc), et de tels systèmes ont été utilisés par les mecs qui utilisent des gros codes parallèles optimisés pour ce genre de problème.
[^] # Re: Transparent huge pages
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Attention, il faut au minimum 3 pages par processus : le code, les données et la pile. Les données pouvant se découper aussi en zone read-only et read-write.
D'un autre coté, avec 4Go de ram, une pages de 2Mo ressemble aux pages de 4ko avec 8Mo de ram. En tout cas, cela vaudrait le cout de faire un teste.
Par contre, le problème restera toujours présent concernant les pages de 1 Go.
"La première sécurité est la liberté"
[^] # Re: Transparent huge pages
Posté par lasher . Évalué à 2.
Oui ben à ce propos, j'ai jamais vu dans la doc Intel où on pouvait avoir des pages d'1Gio. 2MiB iu 4MiB, oui, c'est dedans. Mais sinon je vois pas. L'autre problème est aussi que la taille de la TLB pour les pages de 4Kio est de 128 entrées (de mémoire), alors que pour les grandes pages, il n'y a que 4 entrées (toujours de mémoire). C'est aussi ce qui explique selon moi pourquoi on ne doit pas (pour le moment) avoir des grosses pages par défaut.
[^] # Re: Transparent huge pages
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Il me semble que 1 Go, c'est pour l'itanium, le x86-64, le ppc.
Le nombre de page géré est aussi plus grand que cela selon les CPU.
"La première sécurité est la liberté"
[^] # Re: Transparent huge pages
Posté par Antoine . Évalué à 2.
Sauf que l'utilisation courante n'est pas de faire une fois malloc(1) et puis exit(0) juste après, c'est de faire des allocations multiples. Et des processus qui ne veulent que 4 Ko (sic), de nous jours, il n'y en a pas des masses.
[^] # Re: Transparent huge pages
Posté par gato . Évalué à 2.
Ce n'est pas très élégant ; en outre le préfixe tétra signifie quatre. Un synonyme serait "une quadri-fèce", mais on sent moins le sens. Le mot "floppée" correspond bien, ça fait "flop" quand ça tombe.
[^] # Re: Transparent huge pages
Posté par DLFP est mort . Évalué à 2.
Autant utiliser le préfixe péta.
DLFP >> PCInpact > Numerama >> LinuxFr.org
[^] # Re: Transparent huge pages
Posté par Pierre Jarillon (site web personnel) . Évalué à 10.
Soyons précis : une tétra-chiée ça fait 44.
Bon c'est indubitable, le préfixe tétra signifie quatre. Et une chiée vaut onze parce que onze fait chier.
[^] # Re: Transparent huge pages
Posté par ʭ ☯ . Évalué à 2.
Faux : tétra-chiée fait 4 moins 11, soit moins sept.
⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: Transparent huge pages
Posté par Brice Goglin . Évalué à 5.
Accessoirement, utiliser des hugepage, ca veut aussi dire que tu pagines à la granularité de 2Mo, et donc tu lis/écris 2Mo sur le disque au lieu de 4ko quand tu charges les données et quand tu les swappes. C'est plus lent. On peut toujours fragmenter au moment du swap, mais ca réduit beaucoup l'intérêt du bazar.
Bref, arretez de fantasmer à vouloir mettre des hugepages partout. Y a des moments où c'est clairement utile (gros malloc de 1Go, et c'est ce qui est géré par le THP du 2.6.38). Mais dans le cas général (pile, code, libs, mémoire noyau quelconque, ...), c'est souvent pas une si bonne idée.
[^] # Re: Transparent huge pages
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Le noyau utilise un grosse page de 4Mo depuis le 2.6.0 de mémoire.
"La première sécurité est la liberté"
[^] # Re: Transparent huge pages
Posté par Brice Goglin . Évalué à 1.
Je sais pu où en est cette feature, mais c'était uniquement pour le code et les données statiques en tout cas, pas pour tout le reste que le noyau alloue dynamiquement.
[^] # Re: Transparent huge pages
Posté par neologix . Évalué à 1.
Pour le moment, les hugepage ne sont utilisables que pour des "anonymous pages" (ce qui exclut donc le demand paging et la pagination sur disque) :
P.S. : même avec des pages de 4ko (sur x86), il y a de toute façon un read-ahead lors du demand-paging (sauf si les pages sont marquées VM_RAND_READ).
[^] # Re: Transparent huge pages
Posté par neologix . Évalué à 1.
Juste pour préciser, c'est pas le fait que ce soient des pages anonymes qui empêche le swap...
Pour ce qui est de l'impossibilité, c'était vrai avec les hugepages classiques, maintenant avec THP je ne sais pas ce qu'il en est.
# Terminologie
Posté par oinkoink_daotter . Évalué à 1.
Deux trois imprécisions au sujet du tpm : . Ce n'est pas tres clair dans le texte, mais la SRK n'est pas un module mais une clef. . L'état de la plateforme est contenu dans des registres PCR. L'opération de scellement précise les PCR auxquels on veut lier la clef.
... ...
C'est bizarre markdown...
# dentry
Posté par Brice Goglin . Évalué à 9.
Ouh la non. Le dentry n'est pas le répertoire entier (sinon ca augmenterait les risques d'accès concurrents, et donc diminuerait les chances de pouvoir utiliser le code RCU), le répertoire contient plein de dentry, un dentry par fils en fait (d'où le nom "directory-entry").
Un dentry contient en fait le nom du fils (ou un pointeur vers un nom alloué à coté s'il est très long), un pointeur vers l'inoeud de ce fils, et un pointeur vers le dentry du répertoire parent.
http://lxr.linux.no/#linux+v2.6.38/include/linux/dcache.h#L116
# chaussons
Posté par antistress (site web personnel) . Évalué à 10.
quel bonheur de retrouver la news du noyau linux tous les trois mois, c'est comme enfiler ses chaussons après le travail : on sait qu'on s'y sent bien à l'avance... merci
[^] # Re: chaussons
Posté par Stéphane Téletchéa (site web personnel) . Évalué à 1.
Oui, merci, très intéressant !
# Gardiens du noyau
Posté par Prae . Évalué à 0.
Cependant, quand on sait que certaines décisions sont mauvaises, doit-on courber l'échine ? Comme le disait un des mainteneurs, Linus et d'autres contributeurs ont une vision à eux de ce que doit être Linux (aka "je bosse 24/7 sur un terminal"); Quand je vois les perfs globales de Linux s'effondrer d'année en année, je me pose des questions.
[^] # Re: Gardiens du noyau
Posté par beagf (site web personnel) . Évalué à 10.
Tu as des sources ou des chiffres là-dessus ? De mon expérience personnelle j'ai plus l'impression que c'est l'inverse, les perfs s'améliorent de versions en versions. Ce qui baisse ce sont les perfs des couches supérieures et le noyau n'y peut rien...
[^] # Re: Gardiens du noyau
Posté par lolop (site web personnel) . Évalué à 6.
Tu vois les perfs s'effondrer au niveau du système (Linux), ou au niveau de ton environnement de travail (donc toutes les applications, le système graphique, les nombreux daemons qui bossent en tache de fond...) ?
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Gardiens du noyau
Posté par barmic . Évalué à 8.
%s/Linux/Gnome/ ou %s/Linux/KDE/
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Gardiens du noyau
Posté par monde_de_merde . Évalué à 5.
Quand c'est une décision mauvaise alors il suffit d'arriver avec de bons arguments techniques et/ou des benchmark pertinent et Linus change d'avis, les précédents sont nombreux.
[^] # Re: Gardiens du noyau
Posté par ElectronLibre63 . Évalué à 7.
Vraiment bizarre. Tu parles de linux, ou de l'impression générale. Car pour l'impression générale, j'ai un portable que j'ai acheté en 2002 ou 2003. Je l'ai tout de suite configuré en double boot avec un linux en plus de l'OS imposé, et j'avais vraiment regretté d'avoir acheté le plus bas de gamme car je le trouvais sous linux très poussif (je ne l'ai pratiquement pas utilisé sous l'autre OS). J'ai rapidement augmenté la RAM et changé le disque dur 5400 tr/min par un modèle à 7200 tr/min, ce qui m'a donné dans les deux cas un PC plus réactif. Toutefois, je le trouve aujourd'hui très agréable à utiliser. Bien sûr, il n'est pas aussi réactif qu'un PC récent, mais en tout cas suffisamment pour ne plus avoir envie de le changer. Je ne mets pas à jour mon noyau à chaque sortie, mais plutôt 1 fois sur 5 (oui, je sais, ce n'est pas bien), et à chaque fois je suis surpris de le trouver plus réactif. J'ai même dû récemment remettre mon ancien disque dur dedans, et je me suis attendu à une baisse de performance, et en fait, pratiquement pas.
Par contre, les quelques fois où j'ai reformaté pour repartir sur une distribution toute propre, j'ai eu de nouveau la sensation d'avoir une machine très lente, et je trouve que ça empire à chaque fois. C'est incroyable les dépendances qu'il peut y avoir entre certains paquets, et le nombre de choses qui sont installé par défaut. Après une chasse aux services inutiles et un noyal recompilé aux petits oignons, je retrouve une machine réactive. Donc je dirais plutôt des distributions et des programmes de plus en plus lourds.
Il me semble que les développeurs sont tout de même libres de faire ce qu'ils veulent, non ? Si vraiment les choix étaient si catastrophiques beaucoup seraient parti sur un autre projet, ou forkeraient pour faire prendre une direction tout autre (ça c'est déjà vu sur d'autres gros projets).
[^] # Re: Gardiens du noyau
Posté par Raynor . Évalué à 10.
Je suis depuis pas mal de temps l'évolution du noyau. Et je tiens à rectifier ces deux points :
Linus n'est pas du tout un puriste qui utilise son PC qu'en console. Il a souvent changé de distribution mais utilise maintenant Fedora car c'est une distrib grand publique (il ne veut pas de Gentoo & co). Le desktop est d'ailleurs sa cible principale pour ce qui est des paramètre et algo par defaut dans Linux, car c'est la ou il y a le plus grand nombre d'utilisations differentes. Et aussi car de toute facon les pro des server et de l'embarqué connaissent très bien les options pour adapter Linux à leur utilisation. C'est pas pour rien s'il y a eu autant de patchs qui améliorent l'interactivité ces dernières années.
Pour ce qui est des perfs de Linux: Linux était historiquement optimisé pour une utilisation serveur. C'est à dire avoir le maximum de perf par défaut sans trop se soucier de la latence et de l'interactivité (à quoi bon pour un serveur web). Mais comme je l'ai dis, depuis quelques années Linus essaye de faire en sorte que le kernel fonctionne très bien par défaut pour tout type d'utilisation dont le desktop. Et pour lui avoir des freez d'interface n'est pas acceptable. Il préfère donc échanger quelques % de perf brute coté serveur pour de l'interactivité. Mais tout ca n'est qu'une question de paramètres par défaut, les anciens algo (scheduler CPU, scheduler IO...) sont toujours la, il suffit juste de les activer. Donc pour résumer on a bien perdu des performances au fils des années (ils suffit de regarder les graphs phoronix) mais seulement sur la conf par défaut mais en réalité on a gagné énormément en interactivité. Je le constate moi meme: Linux n'a jamais paru aussi rapide.
[^] # Re: Gardiens du noyau
Posté par Maclag . Évalué à 2.
Signé: un mec qui n'utilise que le terminal 24/7 ?!? ou pas...
# Abondance
Posté par WhiteCat . Évalué à 5.
En effet, dommage que ça ne soit pas pareil pour Mesa.
# merci
Posté par carlo . Évalué à 0.
Comme toujours, merci à patrick_g pour ses très documentées nouvelles sur le développement du kernel.
# erreur à la compilation
Posté par i M@N (site web personnel) . Évalué à 0.
Hello.
Merci à patrick_g pour cette nouvelle dépêche sur le dernier kernel, c'est toujours aussi passionnant à lire.
J'ai une erreur à la compilation et pour le moment je ne comprends pas quel est le problème.
@+...
wind0w$ suxX, GNU/Linux roxX!
[^] # Re: erreur à la compilation
Posté par neologix . Évalué à 2.
Quelle version de gcc ?
[^] # Re: erreur à la compilation
Posté par i M@N (site web personnel) . Évalué à 1.
re ...
4.5.2 je dirais :
Je suis en Debian Wheezy/Sid
J'ai compilé le 2.6.37.3 il y a une semaine sans problème et le 2.6.37.4 est en cours de compilation sans erreur.
J'ai juste activé l'option autogroup automatique et le huge page mais même sans ça j'ai cette erreur.
@+...
wind0w$ suxX, GNU/Linux roxX!
[^] # Re: erreur à la compilation
Posté par neologix . Évalué à 2.
C'est un bug de binutils http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=616357
Si ça ne fonctionne pas, poste un message sur le forum.
P.S. : évite d'utiliser un noyau vanilla...
[^] # Re: erreur à la compilation
Posté par i M@N (site web personnel) . Évalué à 1.
re ...
Merci beaucoup de venir éclairer ma lanterne Mr neologix! : ) Je suis n00b dans la compilation de kernel et j'essaie d'apprendre à le faire en partant de la config du kernel Debian Sid et en configurant via menuconfig quelques options (i915_DKMS, noyau RT, autogroup ...) c'est très intéressant quoiqu'un peu complexe!
Donc il s'agit d'un bug de binutils ... il va me falloir attendre une mise à jour du paquet alors :
C'est quand même étrange (pour moi simple n00b) que le 2.6.37.4 compile en ce moment même sans erreur avec la même version de binutils qui m'empêche de compiler le 2.6.38 ...
Dernière question : pourquoi faut-il éviter d'utiliser un noyau compilé par mes soins depuis les sources de kernel.org? (vanilla c'est bien comme ça qu'on l'appelle?)
@+...
wind0w$ suxX, GNU/Linux roxX!
[^] # Re: erreur à la compilation
Posté par Anonyme . Évalué à 4.
Juste une question, à part parce que c'est Debian, pourquoi ne pas utiliser un noyaux vanilla ?
J'en utilise un tous les jour (ArchLinux) et j'ai jamais eu de problème. C'est pareil pour tous les autres logiciel que j'utilise.
[^] # Re: erreur à la compilation
Posté par neologix . Évalué à 3.
D'abord, pour être sûr de ne pas avoir de problème d'incompatibilité avec l'userland (par exemple udev, X, chaîne de compilation).
Ensuite, parce que le noyau vanilla n'est pas "stable", dans le sens où la plupart des distributions utilisent les branches long term (en ce moment par exemple 2.6.32) avec de nombreux patchs backportés (il suffit de regarder le bruit provoqué par le changement de politique de RedHat au sujet de leur packaging du noyau pour voir combien de patches sont appliqués).
[^] # Re: erreur à la compilation
Posté par barmic . Évalué à 4.
J'utilise vanilla sur Debian depuis quelques version sans problème.
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: erreur à la compilation
Posté par i M@N (site web personnel) . Évalué à 4.
Hello.
Je ne pense pas pas qu'il y ai de gros danger à compiler depuis les sources de kernel.org si on reste assez près de la config du noyau de la distribution. Je pars toujours de la config du noyau le plus récent de Sid (2.6.37 actuellement) avec un make oldconfig et toutes les nouvelles options aux choix par défaut. J'ai jamais eu de problème de cette façon. Et puis c'est tellement intéressant! Sans compter qu'en réactivité j'y gagne beaucoup. Et aussi j'ai les drivers (staging) pour certains matériels (ra2860sta pour le wifi de mon MSi Wind par exemple).
J'ai réussi à compiler le 2.6.38 après avoir downgradé binutils en 2.20.1 (testing)
Parmi les options que j'ai activées : SCHED_AUTOGROUP, TRANSPARENT_HUGEPAGE, PREEMPT, HZ_1000, CONFIG_DRM_I915_KMS
@+...
wind0w$ suxX, GNU/Linux roxX!
# google wakelock
Posté par dufour olivier . Évalué à 7.
Bonjour,
Et pas de news sur le google wakelock/ suspends blokers patch ? Je croyais que c'etait une priorité...
# Tags
Posté par Chris M . Évalué à 1.
Euh, c'est quoi ces tags sur le post ? Oo
[^] # Re: Tags
Posté par dab . Évalué à 1.
C'est vrai que par exemple 2 fois le même tag, c'est important. C'est une feature, ça donne 2 fois plus de poids au tag.
[^] # Re: Tags
Posté par claudex . Évalué à 3.
Ce n'était pas ce qu'il y avait quand il a posté son message. Je suppose qu'ils ont été modéré.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Tags
Posté par Chris M . Évalué à 1.
Merci Xavier de m'avoir évité de passer pour un fou. :)
# Régressions ?
Posté par bubar🦥 (Mastodon) . Évalué à 2.
https://lkml.org/lkml/2011/4/5/172
Linus says :
[^] # Re: Régressions ?
Posté par patrick_g (site web personnel) . Évalué à 4.
C'est sur le 2.6.39 RC1 qu'il y a cette régression je pense. Pas de souci à se faire donc.
[^] # Re: Régressions ?
Posté par bubar🦥 (Mastodon) . Évalué à 2.
J'utilise ce noyau -rc sur mon netbook, qui a besoin du i915.
Crois tu que cette nouvelle règle "no regression" va s'étendre et devenir une règle absolue du noyau ? A suivre ?
[^] # Re: Régressions ?
Posté par bubar🦥 (Mastodon) . Évalué à 2.
J'ai un truc bizarre, dans tout les cas :
Une augmentation des performances 3D après un retour de mise en veille, par rapport aux perfo à l'allumage /o\ La mesure est 'pérave', glxgears, mais faite dans des conditions strictement identiques. (24~26 fps par défaut, entre 33~36 fps après un retour de veille). Surprenant ...
[^] # Re: Régressions ?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Cela peut être dû à une gestion de l'énergie : "à fond" sauf si c'est trop chaud.
"La première sécurité est la liberté"
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.