Le noyau Linux est disponible en version 3.0

Posté par patrick_g (site web personnel) le 22 juillet 2011 à 07:57. Modéré par Xavier Teyssier. Licence CC By‑SA.

Étiquettes :

157

juil.

2011

La sortie de la version stable 3.0 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.

Ce changement de numérotation du noyau est l’occasion de tirer un coup de chapeau aux 176 extralucides du sondage LinuxFr de janvier 2010 qui avaient deviné que ce noyau 3.0 sortirait cette année. Bravo à eux !

Le détail des évolutions et des nouveautés se trouve dans la seconde partie de la dépêche.

PS : Merci à Michel Barret pour avoir contribué à cette dépêche en ajoutant la référence au sondage Linux 3.0.

Sommaire

La phase de test

RC-1

la version RC-1 a été annoncée par Linus :

« Yeah ! Allons‐y pour les interminables discussions à propos de la numérotation du noyau (encore une fois).
J’ai décidé de sauter le pas et de nommer la prochaine version « Linux 3.0 ». Elle sera disponible à une date assez rapprochée de l’anniversaire des 20 ans, pour que je puisse utiliser ça comme excuse. Mais bon, honnêtement, la vraie raison, c’est que je ne suis plus vraiment capable de compter jusqu’à 40.
Nous avions discuté de cette nouvelle numérotation lors des derniers sommets annuels du noyau, et il y avait un plan pour en discuter à nouveau cette année. Mais bon, soyons réalistes, à quoi cela sert-il d’être aux commandes si je ne peux pas prendre une décision sans organiser un référendum ?
Donc, je vais juste me mettre en mode mâle dominant et re‐numéroter le truc. Vous allez adorer ça.
D’un autre côté, ma dominance ne s’étend malheureusement pas sur tous les scripts et les Makefiles, donc le noyau résiste et il s’intitule lui‐même « 3.0.0-rc1 ». Nous aurons les 6 ou 7 semaines habituelles pour arriver à le soumettre et pour nettoyer les scripts de façon à ce que la version finale soit juste « 3.0 ». L’équipe en charge de « -stable » pourra utiliser le troisième chiffre pour ses versions.

Alors, quels sont les grands changements ?
RIEN DU TOUT. Absolument rien du tout. Le 3.0 est juste là pour re‐numéroter, et ici nous ne faisons pas un truc à la KDE 4 ou à la GNOME 3. Pas d’incompatibilités, pas de nouvelles fonctions effrayantes, rien de tout ça. Nous avons fait des sorties basées sur des dates depuis plusieurs années maintenant et cela n’a rien à voir avec des nouvelles fonctions. Si vous voulez vraiment une excuse pour cette re‐numérotation vous devriez vous baser sur les dates (20 ans) et pas sur autre chose.
Pas de changement d’API, pas de changement d’ABI, pas de nouvelles fonctionnalités magiques. Juste la lente et laborieuse progression habituelle. En plus des modifications de pilotes, nous avons quelques nettoyages du VFS, des corrections sur la mémoire virtuelle, un début de consolidation de l’[architecture ARM] et en général tout ceci est supposé être un cycle très classique et normal.

En fait, je pense que ça va être une version du type « Linus est vraiment super ch*ant », et je vais être très strict sur ce que j’accepte pendant la période de stabilisation. C’est parce que je vais voyager la semaine prochaine avec un portable Atom tout lent et que vous aurez intérêt à vraiment me convaincre de l’intérêt de votre patch, puisque ce genre de machine n’est pas le truc le plus impressionnant qui ait jamais été construit. On peut s’en sortir avec le workflow git habituel, mais pour ce qui est de compiler, ce n’est pas vraiment ce à quoi je suis habitué.
Donc, soyez sympas avec moi et envoyez‐moi uniquement des patches importants. Comme ça, la prochaine version n’aura pas simplement un numéro flambant neuf, mais ce sera également un bon noyau.
Ok ? Alors allez-y testez ! »

RC-2

C’est le six juin dernier que Linus a décidé de faire paraître la version RC-2 :

« Vous connaissez tous la procédure maintenant : nouvelle semaine, nouvelle -RC.
Tout a été relativement calme, bien que la mise à jour de Btrfs soit plus grosse que ce que j’espérais. À part ça, il y a surtout des corrections de pilotes, aussi quelques patches pour UBIFS et également une poignée de marche arrière, du fait de certaines régressions.
J’espère que les choses vont rester calmes. Bien entendu, ce calme est peut‐être dû au fait que les gens ont, eux aussi, beaucoup voyagé. Donc, on verra, et autant espérer que tout ira bien.
En plus, je n’ai pas été super pressé de répondre à toutes les demandes d’intégration, donc j’ai encore des requêtes dans ma boîte e‐mail. »

RC-3

Après ses problèmes de réseau lors de son voyage de retour de la convention Linux au Japon, c’est le 13 juin que la troisième version candidate a été annoncée par Linus :

« Qu’avons‐nous là‐dedans ? Plus de trucs que dans la RC-2. Je ne suis certainement pas le seul à être allé au Japon pour la LinuxCon, ou alors il y a un autre truc qui a soudainement réveillé les gens.
Il s’agit surtout de corrections d’une ligne, mais il y a quelques trucs un peu plus gros : pilotes vidéo Radeon, mise à jour DRI, Btrfs, correction de la gestion Sparc [LEON]. D’autres petits trucs concernant NILFS2 et Ceph, et aussi ESA/390 (S/390) et ARM.
À part cela, ce sont juste des mises à jour de pilotes un peu partout.
Comme d’habitude, je demande aux gens de bien tester tout ça. »

RC-4

Réglé comme une horloge, Linus a envoyé son courriel d’annonce de la RC-4 le 20 juin :

« Encore une fois, il y a surtout de petites corrections d’une ligne et quelques changements dans DRM (et md).
Et aussi des patchs pour des régressions de performances : RCU n’a pas besoin de threads (et ne pas les utiliser corrige certains problèmes de performances sous des charges spécifiques) et la conversion des “spinlocks” en “mutexes” pour anon_vma a provoqué des soucis de montée en charge et a dû être corrigée. »

RC-5

La version RC-5 a été annoncée par Linus le 27 juin :

« Pas grand chose d’excitant là‐dedans.
Le truc le plus notable est peut‐être le fait que seulement un quart des changements concernent les pilotes. Les systèmes de fichiers représentent plus que ça (40 %) : Btrfs, CIFS, ext4, JBD2, NFS, ils sont tous là.
Et on trouve aussi tous les petits changements un peu partout. Comme, par exemple, des corrections d’échecs de compilation (pour être honnête vous devez activer quelques options ésotériques et désactiver NUMA pour rencontrer ce bogue, mais bon). Il y a encore quelques soucis en « staging » avec des correctifs en attente d’intégration. »

RC-6

Le 4 juillet, jour de la fête de l’indépendance aux États‐Unis, Linus a rendu disponible la version RC-6 du noyau :

« Joyeuse fête de l’indépendance pour tous les américains qui bossent sur le noyau là dehors.
Il n’y a pas grand chose à dire sur cette RC-6. La plus grosse partie, et de loin, c’est l’inclusion du pilote Intel isci. J’ai un peu hésité à son sujet, mais bon, ce n’est pas comme si ça allait causer des régressions pour des utilisateurs de Linux, donc pourquoi pas.
Et puis, franchement, Christoph Hellwig a dit des choses flatteuses sur ce pilote à deux reprises, ce qui est très inhabituel. Cela peut vouloir dire que ce pilote est génial. Bien entendu, il est bien plus probable que des aliens venus de l’espace soient juste en train de tester secrètement leur drogue euphorisante sur Christoph. Ou alors, il s’adoucit avec l’âge.
À part ce pilote isci, le reste est juste constitué de petites corrections. On en arrive au point où je commence à songer à sortir le noyau 3.0, parce que tout est vraiment calme et que les correctifs n’ont pas été révolutionnairement excitants. Quelques trucs sur le DRM (Radeon et Intel) seront peut‐être remarqués par plus de gens, mais le reste tend à être assez ésotérique.

Bon, maintenant, je me barre pour faire des “s’mores”. »

RC-7

Linus, après avoir hésité, a finalement décidé de sortir une ultime version candidate le 11 juillet dernier :

« J’avais dit que la RC-6 serait sans doute la dernière. J’ai menti.
Les choses ont été assez calmes, mais il y avait quand même suffisamment de trucs pour que je veuille une autre RC. Et puis nous avons quelques soucis avec les changements dans le RCU qui posent des problèmes quand l’ordonnanceur n’a pas été complètement initialisé. Donc, voici la RC-7, même si elle n’a peut‐être pas encore été répliquée sur les miroirs au moment ou j’écris.
Il n’y a pas grand chose à en dire. Des mises à jour de pilotes (nous sommes revenus au ratio habituel avec deux tiers pour les pilotes), quelques changements dans media et CIFS, et aussi des améliorations de détail sur vmscan. »

Un léger retard

Alors que Linus avait prévu de sortir le noyau 3.0 le lundi 18 juillet, il a finalement préféré attendre un peu en raison de problèmes de dernière minute.
C’est d’abord Hugh Dickins qui a trouvé un bogue difficile à mettre en évidence et assez compliqué à corriger dans la fonction de résolution de noms. Une fois cela résolu, c’est Paul McKenney qui s’est manifesté sur la LKML et qui a signalé avoir découvert plusieurs dysfonctionnements dans le code RCU du noyau.
Le temps pour Linus d’intégrer les patches proposés et de demander aux gens de tester via son nouveau compte Google+ rutilant, le planning soigneusement orchestré était bon à jeter aux orties.
Ces retards auront un impact sur le prochain noyau, puisque Linus avait prévu de partir en vacances juste après la fin de la période d’intégration des nouveautés du futur Linux 3.1. Il a envoyé un e‐mail récapitulatif pour expliquer la situation et laisser entendre qu’il sera particulièrement féroce envers les malheureux qui n’enverront pas leurs patches assez tôt.

Les nouveautés

Cleancache

Le patch cleancache, qui repose sur le mécanisme Transcendant memory évoqué dans la dépêche du noyau précédent, a été intégré dans Linux 3.0.

Pour bien comprendre le rôle de cleancache, il faut d’abord jeter un très bref regard sur la gestion de la mémoire.
Il y a en premier lieu une division entre la mémoire physique — la RAM — et la mémoire virtuelle qui présente aux applications un espace d’adressage qui leur est propre. Comme les deux sortes de mémoires sont divisées en pages, il faut des tables de correspondance entre une page physique et une page virtuelle. Ces tables sont nommées, de façon fort originale, des page tables.

On peut marquer les pages mémoires en mettant des drapeaux particuliers. Par exemple, si le drapeau « dirty » est appliqué, cela signifie qu’une application a voulu écrire des données et a utilisé la fonction write(). Le noyau a copié ces données dans des pages mémoire en leur mettant un drapeau « dirty ». Ces pages ne doivent donc pas être réutilisées tant que les données n’auront pas été effectivement écrites sur le disque dur.
Évidemment, à l’inverse, les pages ayant le drapeau « clean » sont disponibles pour être utilisées à tout moment.
Quand la pression mémoire est trop importante, alors les pages en statut « clean » peuvent être « enlevées » de la mémoire physique. Ce mécanisme d’éviction (memory reclaiming) va enregistrer les pages dans leur espace de stockage particulier. Cet espace, nommé backing store, c’est tout simplement le disque ou la partition d’échange (swap) de la machine.

C’est ici qu’intervient le patch « cleancache » écrit par Dan Magenheimer. En cas d’éviction d’une page mémoire clean par l’algorithme dédié, alors le mécanisme cleancache va jouer le rôle d’un victim cache, c’est‐à‐dire qu’il va accueillir les pages retirées de la mémoire pour les stocker dans un espace à accès plus rapide que le backing store sous‐jacent.
Maintenant, on comprend mieux ce nom de « cleancache », puisqu’il s’agit simplement d’un mécanisme de cache pour les pages ayant le drapeau « clean » ;-).

Alors évidemment, une première question se pose : si on stocke les pages victimes d’éviction dans un cache, cela signifie qu’on a de la place disponible, non ? Alors, pourquoi ont‐elles été choisies par le mécanisme de memory reclaiming qui n’intervient qu’en cas de manque de mémoire ?
La réponse est que cleancache n’utilise pas la mémoire classique. L’idée est de se servir d’un espace de stockage intermédiaire, n’importe lequel, puisque cleancache est agnostique envers son réservoir sous‐jacent. Le noyau Linux 3.0 permet ainsi d’utiliser la mémoire de l’hyperviseur si on tourne avec Xen, ou bien encore le mécanisme zcache de mémoire compressée. D’autres mécanismes sont en cours de développement, comme par exemple un SSD qui se place entre la RAM et le disque dur. Ce SSD servirait ainsi pour stocker les pages de cleancache afin de pouvoir y accéder bien plus rapidement qu’en cas d’appel au très lent disque dur.

Si on regarde la documentation, on voit que cleancache a été conçu pour s’interfacer avec le mécanisme VFS. Les systèmes de fichiers qui veulent utiliser ce mécanisme doivent effectuer un appel à cleancache_init_fs() lors du montage initial. À l’heure actuelle, les systèmes de fichiers ext3, ext4, Btrfs et OCFS2 peuvent utiliser cleancache (évidemment, dans le cas où l’option CONFIG_CLEANCACHE a été choisie lors du build).
Lors de l’éviction d’une page par le noyau, la fonction cleancache_put_page() sera appelée pour entreposer la page dans la zone de cache spéciale de cleancache. Si par la suite il s’avère que le noyau a besoin de cette page, il va, avant de lancer une coûteuse requête vers le disque dur, effectuer une recherche rapide via cleancache_get_page(). En cas de succès, c’est‐à‐dire si la page était toujours présente dans le cache, on peut gagner un temps précieux et augmenter largement les performances.
Comme l’indique Dan Magenheimer :

En réalité, cleancache remplace des opérations d’entrées‐sorties qui impactent le disque par des opérations de copie mémoire qui impactent le processeur. Sur des vieux systèmes ayant un seul processeur et une mémoire lente, cleancache ne sert pas à grand chose. Sur les nouvelles machines multi‐cœurs, spécialement dans un environnement virtualisé, le mécanisme a alors une grande utilité.

Afin de garder un œil sur cette fonction et de vérifier son apport en termes de performances, diverses statistiques sont accessibles dans le répertoire « /sys/kernel/mm/cleancache ». On y trouve :

succ_gets, le nombre d’appels à cleancache_get_page() ayant réussi (la page était dans le cache) ;
failed_gets, le nombre d’appels à cleancache_get_page() ayant échoué (la page n’était pas dans le cache) ;
puts, le nombre d’appels total fait à cleancache_put_page() pour déposer une page dans le cache ;
flushes, le nombre d’appels total fait à cleancache_flush_page() pour retirer une page du cache.

Cleancache, en association avec le patch Transcendant memory, est un mécanisme très générique et adaptable, et il est probable que nous commençons à peine à profiter de ses bénéfices dans le noyau Linux 3.0.
L’arrivée dans les prochaines années des RAM non‐volatiles (qu’elles soient à base de memristors ou de verre de chalcogénure), permet d’imaginer un espace de stockage intermédiaire plus lent que la RAM, mais plus rapide que les disques (même SSD). Ce serait certainement une situation idéale pour la technique cleancache introduite dans ce noyau.

Améliorations de Btrfs

Après la décision de Fedora d’utiliser Btrfs par défaut dans sa prochaine version 16, il est peut‐être temps de réaliser un point de situation global sur ce très moderne système de fichiers. L’occasion est belle car, selon Chris Mason, les patches Btrfs intégrés dans le noyau Linux 3.0 sont les plus importants depuis le début du développement du système de fichiers.

C’est en juin 2007 que Chris a annoncé sur la liste de diffusion la naissance de Btrfs. L’idée était de créer un nouveau système de fichiers ultra‐moderne et profitant de toutes les dernières idées, sans être contraint par un quelconque souci de rétro‐compatibilité avec l’existant. C’est sans doute l’aiguillon de ZFS, disponible dans Solaris à partir de 2005, qui a poussé les développeurs Linux à lancer l’écriture d’un système de fichiers plus avancé que la série des ext2/3/4, et plus pérenne que ReiserFS.

Si l’on en croit l’excellent historique de Btrfs écrit par Valérie Aurora, tout est parti d’une idée du chercheur Ohad Rodeh, qui a trouvé un moyen élégant de combiner les avantages des « arbres B » (B‐trees) et du « Copy‐On‐Write » (COW). Les arbres B sont un moyen de représenter les données d’un système de fichiers ou d’une base de données dans un arbre dont chaque nœud possède plus d’une clé. C’est une technique très efficace, mais, jusqu’à la percée théorique de Rodeh, les arbres B ne pouvaient pas être combinés avec la technique d’optimisation connue sous le nom de Copy‐On‐Write. Avec le COW, si des données sont écrites sur un bloc mémoire, alors les nouvelles données seront enregistrées sur une copie au lieu de l’être sur l’original. Ensuite, les méta‐données pointant sur le bloc sont modifiées de manière atomique, afin de prendre en compte les nouvelles données. On a ainsi un mécanisme transactionnel efficace et tellement rapide qu’on peut même abandonner la technique de « journalisation ».
Le problème de mixage des arbres B avec le COW est que dans un arbre B les « feuilles » sont liées entre elles. Quand l’emplacement de la première feuille change suite à une opération d’écriture (puisque le COW implique la copie du bloc à un autre endroit), alors la feuille adjacente doit changer son lien, ce qui implique via COW une copie à un autre endroit… et bis repetita avec toutes les feuilles de l’arbre ! Bien entendu, comme vous pouvez l’imaginer, ce n’est pas très bon pour les performances de devoir réécrire tout l’arbre du système de fichiers à chaque modification d’une feuille…

L’idée d’Ohad Rodeh (décrite dans ce fichier PDF de la conférence USENIX) est d’utiliser un B+tree à la place d’un classique B‐tree. Les feuilles ne sont plus liées irrémédiablement entre elles, et on peut inventer des algorithmes astucieux pour traverser l’arbre. Rodeh ajoute des techniques comme la « fusion et séparation pro‐active des nœuds », et on obtient au final ce que Valérie Aurora qualifie de :

« structure de données simple, robuste et générique qui prend en compte de façon très efficace les extends (groupes de blocs de données contigus) dans un système de fichiers COW. »

Chris Mason a été frappé par la puissance et l’élégance de ce concept, et il a décidé de baser toute l’architecture de Btrfs sur cette idée. Il a choisi d’implémenter l’intégralité des « objets » du système (inodes, données des fichiers, répertoires, bitmaps) comme étant des nœuds ou des feuilles de l’arbre B. De cette façon, on n’écrit qu’un seul code qui est utilisé partout, et on peut avoir toutes les fonctions utiles (sommes de contrôle, snapshots, compression, etc.) qui s’appliquent à ce code unifié. On peut également profiter d’avantages en termes d’efficacité de stockage et de temps d’accès. Les autres systèmes stockent un seul type d’objet par bloc, ce qui est peu efficace, puisqu’on perd de la place dans le bloc et qu’on doit consulter plusieurs blocs pour avoir toutes les méta‐données. La stratégie de Btrfs rassemble tout dans une structure qui optimise l’espace disque et le temps d’accès.

Valérie Aurora a travaillé plusieurs années sur ZFS dans l’équipe de développement de Sun. Elle est donc particulièrement bien placée pour émettre un jugement solide en comparant ces deux systèmes de fichiers. La citation est un peu longue, mais elle a le mérite de la franchise :

« La conception de Btrfs est d’une grande élégance et d’une belle généricité […] Les gens me posent souvent des questions au sujet de ZFS et Btrfs. D’un certain point de vue, les deux systèmes sont très similaires : ce sont des systèmes de fichiers COW avec sommes de contrôles, gestion de périphériques multiples et des instantanés (snapshots) accessibles en écriture.
Selon un autre point de vue, ils sont extrêmement différents : Btrfs organise tout sur le disque en termes d’extents dans un arbre B qui contient toutes les données. ZFS organise tout sur le disque en termes d’arbres de pointeurs vers les blocs, avec des tailles de blocs en fonction de la taille de l’objet.
Donc la liste des fonctions des deux semble très similaire, mais les implémentations sont complètement différentes. C’est un peu comme le cas de l’évolution convergente entre les marsupiaux et les mammifères. Une souris marsupiale et une souris mammifère semblent complètement identiques vues de l’extérieur, mais leur implémentation interne est quelque peu différente !
À mon avis, l’architecture de base de Btrfs est mieux adaptée au stockage de données que celle de ZFS.
Un des problèmes majeurs de l’approche de ZFS à avoir un ensemble de blocs de tailles différentes, concerne la fragmentation. Chaque objet ne peut contenir que des blocs d’une seule taille. On peut facilement se retrouver avec un fichier formé à partir de blocs de 64 Kio qui doit grossir d’un bloc, alors qu’il n’y a plus de blocs de 64 Kio disponibles (alors qu’il y en a encore beaucoup de 512 octets, de 4 Kio, de 128 Kio, etc.).
Pour résoudre ce problème, nous (les développeurs de ZFS) avons inventé des façons de créer des gros blocs à partir de plus petits (gang blocks), et beaucoup d’autres contournements assez vilains. Pour notre défense, à cette époque, les arbres B et la technique COW semblaient radicalement incompatibles.
Par contraste, l’approche Btrfs qui place tous les items dans l’arbre B est extrêmement flexible et efficace en termes d’espace de stockage. »

Depuis sa présentation initiale en 2007, le système de fichiers Btrfs a beaucoup évolué, et il propose de nombreuses fonctions modernes parmi lesquelles on peut citer :

notion de « sous‐volumes » qui permet, au sein du système de fichiers, d’avoir un arbre séparé contenant des répertoires et des fichiers. Les instantanés (snapshots en anglais, une photographie à un instant donné du système de fichiers) sont simplement des sous‐volumes accessibles en écriture via COW ;
sommes de contrôle des données et méta‐données ;
agrandissement et réduction de taille des volumes ;
ajout et suppression de volumes ;
fonctions de compression transparente ;
fonctions RAID intégrées.

Pour le noyau Linux 3.0, Chris Mason a décrit les changements présents dans sa branche de développement. Il y en avait tellement qu’il a dû envoyer une nouvelle bordée de patches au moment de la RC-2 (ce qui lui a valu la traditionnelle engueulade de la part de Linus).
Une des modifications les plus importantes est le patch de Miao Xie qui réécrit la fonction d’insertion des méta‐données dans les inodes. Intitulé « Delayed Inode Items Operation », ce patch vise à améliorer les temps de création et suppression de fichiers. L’insertion de méta‐données dans le B+tree étant coûteuse, le nouveau code introduit une double liste qui stockera les opérations au lieu de bloquer, et ensuite le travail sera effectué par un thread spécifique (worker).

Selon le banc d’essai passé par Miao Xie :

création de 50 000 fichiers :
- avant le patch : 1,096 108,
- après le patch : 0,932 899 (soit un gain d’environ 15 %) ;
suppression de 50 000 fichiers :
- avant le patch : 1,510 403,
- après le patch : 1,215 732 (soit un gain d’environ 20 %).

On peut également citer le patch de Li Zefan qui implémente un cache pour les numéros d’inodes, afin de ne pas risquer d’en tomber à court sur les machines 32 bits.
Il y a aussi le patch d’Arne Jansen qui ajoute la prise en charge des fonctions de scrubbing. En gros, cela va permettre d’ordonner au noyau (via un ioctl) de vérifier les sommes de contrôles des extents et des superblocs présents sur le volume de stockage. En cas d’erreur (perte d’intégrité), une copie saine sera recherchée dans les volumes sauvegardés et une correction automatique sera effectuée. Selon les commentaires présents dans le code, ce travail sera complété dans une prochaine version pour ajouter des fonctions de « readahead » plus avancées (meilleures performances) et des fonctions de rapport en cas d’erreur irréparable.
Chris Mason a écrit un patch qui permet l’auto‐défragmentation de fichiers en cas d’accès aléatoires en écriture. Le patch permet de détecter ces accès particuliers et s’occupe de mettre les fichiers dans la liste pour une défragmentation automatique. Cette fonction s’active via « mount -o auto_defrag » et elle est décrite comme particulièrement adaptées pour des fichiers de taille réduite comme on peut en trouver dans des base de données du type SQLite ou Berkeley_DB.

Si on ajoute à ça la gestion de cleancache, le gros travail de nettoyage de code de David Sterba (17 patches pour 310 lignes en plus et 3 253 lignes en moins) et les efforts d’optimisation des performances entrepris par Josef Bacik et listés dans le courriel de Chris Mason, on comprend que le système de fichiers Btrfs présent dans le noyau Linux 3.0 a été grandement amélioré. La seule pièce manquante pour le choix définitif de Btrfs par défaut dans Fedora 16 ne concerne pas vraiment le noyau, puisqu’il s’agit d’ajouter un programme de vérification du type fsck. Selon Josef Bacik, cet outil est déjà écrit et il est en phase de vérification intensive :

L’outil de fsck est presque prêt. Une partie des raisons pour lesquelles cela prend autant de temps, c’est qu’il est très bien testé. Donc, quand il sera rendu disponible, il aura vérifié plusieurs centaines de systèmes de fichiers corrompus afin de s’assurer qu’il fonctionne correctement.

POSIX Alarm timer

Deux nouvelles interfaces d’accès à l’horloge RTC du BIOS font leur entrée dans le noyau Linux 3.0.

Cette horloge RTC est bien pratique, puisqu’elle permet de réveiller automatiquement la machine quand elle est en veille ou en hibernation, par exemple pour faire une sauvegarde au milieu de la nuit ou pour enregistrer une émission. Pour cela, il suffit à une application d’écrire dans « /sys/class/rtc/rtc0/wakealarm » pour indiquer la date et l’heure du réveil souhaité. L’horloge RTC reste à l’heure même si l’ordinateur hiberne et, juste au moment voulu, elle génère un signal pour réveiller la machine et passer la main au programme utilisateur.
L’ennui c’est qu’il s’agit d’une interface bas niveau et qu’une seule application peut programmer le réveil de l’ordinateur. C’est le premier arrivé qui gagne ! Si l’on veut à la fois programmer une sauvegarde, puis l’enregistrement d’une émission, alors il faut ruser. On peut s’en sortir en faisant coopérer les applications et en jouant avec cron, mais ça devient beaucoup plus compliqué.
L’idéal ce serait que les applications signalent simplement leurs besoins dans une sorte de file d’attente (timerqueue), et que le noyau s’occupe tout seul du travail consistant à réveiller la machine au moment spécifié le plus proche dans le temps. Le programme en espace utilisateur envoie un rtc_timer dans la queue au lieu de parler directement à l’horloge RTC. Cette fonction si pratique de « virtualisation » de l’horloge RTC (puisqu’on passe par une couche intermédiaire) est entrée dans le noyau à partir de la version 2.6.38.

Maintenant il faut s’attaquer à la partie visible par les applications. Comment leur proposer une interface simple qui cache tous les horribles petits détails bas niveau comme, par exemple, les désynchronisations entre l’horloge RTC et l’heure système ? Quelle est la meilleure solution pour donner suffisamment d’informations aux applications, tout en ayant une API robuste et sûre ?
C’est une question délicate, car toute interface vers des applications en espace utilisateur devient, une fois publiée, absolument intangible. Si l’on fait du mauvais travail au début, il est très difficile de corriger les choses par la suite, puisque cela risque de casser la compatibilité avec les applications.
Dans ces cas‐là, il est toujours utile de regarder autour de soi pour voir quelles sont les solutions adoptées par les autres systèmes.

Par exemple, l’équipe d’Android a déjà développé plusieurs nouvelles interfaces d’horloges pour son système (un téléphone se met souvent en veille automatique, et il a besoin de sortir de cet état à des moment bien précis). Pourquoi ne pas réutiliser ce travail ?
Malheureusement, au lieu de participer au développement dans la branche principale, ils ont codé dans leur coin des choses assez peu orthodoxes du type ANDROID_ALARM_RTC ou ANDROID_ALARM_SYSTEMTIME, ou encore ANDROID_ALARM_ELAPSED_REALTIME. Ces interfaces n’utilisent pas du tout « /sys/class/rtc/* », elles passent par un tout nouveau périphérique en mode bloc « /dev/alarm » et envoient des commandes via un ioctl.
Évidemment, pour rajouter un peu de bonheur dans le cœur des développeurs Linux, certaines de ces interfaces réinventent la roue et reprennent en partie des concepts qui existent déjà dans le noyau (CLOCK_REALTIME et CLOCK_MONOTONIC). Seule l’interface ANDROID_ALARM_ELAPSED_REALTIME est intéressante et nouvelle, puisque non seulement elle compte le temps qui s’est écoulé depuis le démarrage du système, mais surtout, elle tient compte des phases de veille et d’hibernation dans son calcul. C’est un avantage par rapport au classique CLOCK_MONOTONIC qui compte le temps à partir de zéro depuis le démarrage du système, mais qui s’arrête de compter quand la machine hiberne.

Le développeur John Stultz s’est donc inspiré du travail intégré dans Android, et il a codé deux nouveaux types d’horloges pour Linux 3.0.
La première, CLOCK_REALTIME_ALARM, étend la classique CLOCK_REALTIME, qui ne faisait que donner l’heure RTC, et ajoute la possibilité de réveiller l’ordinateur. La seconde horloge se nomme CLOCK_BOOTTIME_ALARM et elle copie les fonctions d’ANDROID_ALARM_ELAPSED_REALTIME. On a donc un compteur qui s’incrémente depuis zéro à partir du démarrage du système et qui ne s’interrompt pas lors des phases de veille et d’hibernation.
Ces horloges sont implémentées par dessus le mécanisme de virtualisation qui avait été introduit dans le 2.6.38, et, contrairement au code d’Android, elles utilisent l’interface classique POSIX et parlent à l’horloge RTC sous‐jacente en utilisant les évènements rtc_timer décrits plus haut.

C’est donc une belle avancée pour Linux, mais cela ouvre également des perspectives pour les développeurs d’Android. Ils avaient développé des interfaces dans leur coin parce que le noyau ne leur proposait pas ce dont ils avaient besoin. Maintenant que CLOCK_REALTIME_ALARM et CLOCK_BOOTTIME_ALARM sont dans la branche principale, pourquoi ne pas simplement les utiliser, puisqu’elles offrent les mêmes fonctions que le code spécifique d’Android ?
John Stultz a parlé aux développeurs de Google, et, selon lui, il semble qu’une simplification et qu’un large partage de code soit devenu maintenant possible.

Suppression de prefetch

Les appels à la fonction prefetch() qui parsemaient le noyau ont été en grande partie retirés dans cette version 3.0. Le travail de nettoyage va sans doute se poursuivre dans les versions futures, car les tests ont montré que les gains en performances qui étaient espérés avec cette fonction ne sont pas au rendez‐vous.

La fonction prefetch() est ce que l’on nomme une « micro‐optimisation ». C’est‐à‐dire que son rôle est d’améliorer à la marge les performances du noyau en complexifiant un petit peu le code. Bien entendu, chaque micro‐optimisation est le résultat d’un calcul coût‐bénéfice assez spéculatif : est‐ce que le gain en performances justifie la complexité qui est ajoutée dans le code et qui risque d’introduire des bogues et de la charge de maintenance ?
Les développeurs du noyau savent parfaitement que les performances d’une machine dépendent de façon cruciale de la mémoire cache (voir l’article d’Ulrich Drepper sur ce sujet). La différence de temps d’accès entre une mémoire cache gravée sur le processeur et une barrette de RAM externe est tellement gigantesque, que tout défaut de cache réduit de façon importante les performances. Il faut donc que le code du noyau fasse le maximum pour que la gestion du cache soit la plus efficace possible.

Pour cela, des appels à prefetch() ont été ajoutés dans plusieurs endroits du noyau. Par exemple, quand des listes chaînées sont utilisées, on va utiliser prefetch() pour charger en avance l’item suivant de la liste. Le processeur sera toujours en train de traiter l’élément n de la liste, mais, grâce à ce chargement anticipé, l’élément n + 1 aura été appelé en avance de phase et sera, soit sur le chemin vers le processeur, soit déjà au chaud dans la mémoire cache. On perd ainsi moins de temps à interroger la RAM et à se rouler les pouces en attendant sa réponse.
Les macros existantes dans le noyau Linux, comme list_for_each par exemple, incorporent donc un appel à cette fonction de pré‐chargement en tant que micro‐optimisation permettant d’accélérer le traitement des listes chaînées.

La fonction prefetch() est, on le voit, une idée simple, naturelle et non controversée. Le problème c’est qu’en réalité il s’avère qu’elle dégrade les performances !
Tout cela vient du fait que les processeurs modernes sont des monstres d’ingénierie, avec un « budget transistor » absolument indécent. Pour augmenter les performances, les têtes pensantes des labos d’AMD, Intel ou IBM ont bien compris qu’optimiser le chargement de la mémoire cache était crucial. Tous les CPU modernes incorporent donc des unités matérielles de pré‐chargement des données. Ce prefetcher matériel observe donc les accès mémoire et il arrive à distinguer des schémas récurrents (patterns) qui vont lui permettre de pré‐charger les données en avance de phase. Chaque constructeur garde jalousement le secret sur le fonctionnement exact de ces unités matérielles de pre‐fetch (la documentation est très succincte), mais le résultat est là : le processeur fait du bon travail et parvient de lui‐même à optimiser le fonctionnement de la mémoire cache en pré‐chargeant efficacement les données.

À ce stade un problème se profile à l’horizon : si le processeur est déjà capable de faire du pré‐chargement, alors à quoi est‐ce que ça sert d’ajouter des appels à prefetch() partout dans le code ? On risque plutôt de perturber les flux de données en interférant avec le délicat travail du processeur.
C’est cette réflexion qui a conduit Andi Kleen, dès septembre 2010, à proposer son patch de nettoyage des appels à prefetch().
Andi s’est penché sur cette question pour évaluer l’apport réel du pré‐chargement codé dans le noyau. Il a parlé avec des ingénieurs CPU, et la conclusion est sans ambiguïté :

Le retour de la part des concepteurs de CPU, c’est qu’ils n’aiment pas quand nous utilisons des appels explicites à prefetch(), à moins qu’il n’y ait une très bonne raison de le faire.

Si l’on ajoute le fait que les appels de pré‐chargement augmentent la pression sur les registres du processeur et que le code généré par les compilateurs est souvent de moins bonne qualité quand il y a des appels à prefetch(), alors le résultat du calcul coût‐bénéfice change du tout au tout.
L’ennui c’est que le patch d’Andi de septembre dernier n’a pas suscité une réaction d’enthousiasme démesurée sur la liste de diffusion du noyau. En fait, il n’y a pas eu de réaction du tout, à part un e‐mail de Paul Moore disant en substance : « Ouais, pourquoi pas ? ».
Il ne faut pas oublier que la LKML se caractérise par un déluge de courriels, et il n’est pas rare de voir ainsi des propositions rester sans suite. C’est au développeur qui a créé le patch d’insister et de défendre son travail inlassablement pour obtenir une réaction de ses pairs. Dans le cas d’espèce, Andi n’a pas insisté et son nettoyage des appels à prefetch() n’a pas été intégré dans la branche principale du noyau.

Tout change le 19 mai 2011 avec un e‐mail de Linus intitulé « Software prefetching considered harmful ». Avec son style fleuri habituel, le leader du noyau détaille les tests qu’il a effectués et tout le bien qu’il pense de la fonction de pré‐chargement :

J’ai passé un peu de temps ces derniers jours à regarder les performances du noyau sur une tâche que j’effectue en permanence : « make » sur un répertoire qui est déjà complètement « buildé ». Donc, il n’y a pas le coût de la compilation, juste le coût de _vérification_ de ce qui doit être compilé.
Il s’avère que « make » est franchement lent comme un goret (quoi de neuf là‐dedans ?), mais que cette charge est assez intensive pour le noyau. On passe un bon paquet de temps à faire de la résolution de noms. Et nous sommes bons en matière de résolution de nom… sauf si je veux activer SELinux sans perdre les avantages de la résolution via RCU. Dans ce cas de figure, SELinux suce des fœtus d’ânes à travers une paille.
Quoi qu’il en soit la fonction la plus consommatrice est celle qui utilise le prefetch logiciel pour les listes de hachage. Le profil montre clairement que l’instruction de prefetch est de loin la plus grande coupable.
Et ce n’est pas à cause des défauts de cache. En réalité, la suppression du prefetch AUGMENTE LES PERFORMANCES.
Je ne blague pas. C’est juste une merde. C’est une immonde merde qui nous coûte 0,5 % de performance sur un simple banc d’essai de « make » du noyau sur l’un des processeurs les plus communs qui existent.
Sérieusement.

Le patch qui accompagne le courriel indigné de Linus supprime donc la fonction de pré‐chargement des listes de hashes (hlist) et relance l’intérêt pour mener des investigations sur la fonction prefetch(). Ingo Molnar s’est engagé dans une phase de test intensive à l’aide de l’outil perf pour comprendre clairement ce qui se passait.
Le résultat de ses investigations a été résumé dans un message très détaillé dont j’extrais la conclusion :

- Depuis des années, les gens ajoutent des instructions de prefetch à l’aveuglette, sans tester et sans prouver qu’il y a vraiment un gain. Nous devrions réexaminer tout cela soigneusement.
- Le processeur est fondamentalement plus efficace que le logiciel dans le domaine du pré‐chargement. Nos fameuses instructions se révèlent diminuer les performances.
- Les tests, via les perf‐events, sont la voie à suivre. Ils se sont révélés très utiles pour moi, afin d’analyser la situation. Et je n’ai même pas eu à me préoccuper de quel modèle de CPU était utilisé lors des tests. C’est un énorme avantage à mon avis.

Après la diatribe de Linus et les analyses d’Ingo (qui va jusqu’à dire que « les pré‐chargements sont absolument toxiques »), il était clair que la fonction prefetch() du noyau n’allait pas en sortir indemne. En septembre 2010, Andi Kleen avait été un précurseur incompris, mais aujourd’hui la nécessité d’agir est devenue évidente.
Dans le nouveau noyau Linux 3.0, la fonction prefetch() a donc été retirée des listes de hashs et des listes chaînées. Les pilotes commencent également à être nettoyés eux aussi.
Le gain induit par ces changements est marginal (entre 0,5 et 1 %), mais là n’est pas l’important. Ce qui compte, c’est que le code est maintenant plus simple, plus maintenable et que la taille d’une image noyau est un peu réduite (Andi Kleen avait chiffré le gain à 10 Kio). Ce qui compte surtout, c’est que les outils de diagnostic intégrés au noyau (perf et ses amis) permettent maintenant de se pencher efficacement sur les micro‐optimisations du noyau et d’évaluer leur apport réel.
Ingo Molnar, l’un des auteurs de perf, n’est évidemment pas neutre quand il défend son bébé. Mais il a raison de souligner les gains que cela permet :

Durant ces dix dernières années, nous avons souffert d’un niveau d’aveuglement croissant en ce qui concerne l’analyse des performances x86. Nos outils se sont lentement détériorés, les processeurs sont devenus de plus en plus intelligents et parallèles, et c’était de plus en plus difficile de comprendre ce qui se passait.
Mais nous avons maintenant de meilleurs outils (clin d’œil :) et un modèle de supervision plus performant (clin d’œil :), et les gens recommencent à se plonger dans les petits détails. Je pense que nous avons de bonnes chances d’améliorer encore les performances du noyau et de les maintenir à ce niveau.

Un JIT pour BPF

Le code de la pile réseau du noyau Linux 3.0 contient désormais un compilateur à la volée (JIT) qui permet d’accélérer le traitement des paquets réseau du filtre Berkeley Packet Filter.

Le filtre BPF (Berkeley Packet Filter), présenté à la conférence USENIX de 1993, est un outil qui permet à un logiciel en espace utilisateur de spécifier, via des filtres, les paquets pour lesquels il éprouve un intérêt. BPF a été rapidement intégré directement dans le noyau Linux qui y a gagné la possibilité de filtrer en amont les paquets du réseau et de n’envoyer vers l’application que le strict nécessaire dont elle a besoin.
Ainsi, on gagne en performances car on bloque les paquets inutiles dans le noyau dès le début, avant d’avoir à les envoyer vers l’espace utilisateur.

Parmi les logiciels qui reposent sur BPF, on peut citer ngrep, Wireshark ou encore tcpdump, qui servent à capturer et analyser des paquets réseau. Ils utilisent BPF en positionnant un filtre précis qui ne va laisser passer que ce qui est intéressant. Ces logiciels reçoivent ainsi un flux « propre » puisque débarrassé de tous les paquets qui ne correspondent pas à leurs critères de recherche.
Évidemment, on comprend que les performances de BPF dans le noyau sont assez critiques, puisqu’il va devoir examiner les paquets un par un et déterminer s’ils correspondent ou pas aux conditions paramétrées dans le filtre.

Pour Linux 3.0, l’idée d’Éric Dumazet a consisté à ajouter au code de BPF (lisible dans « net/core/filter.c ») un mécanisme de génération de code à la volée (Just‐in‐time compilation). Chaque instruction du filtre va être transformée en assembleur, et le programme qui en résulte traite chaque paquet réseau pour voir s’il correspond aux conditions de test.
Si vous prenez la peine de regarder le code de BPF, vous verrez (ligne 190) que c’est essentiellement un gros switch() qui énumère tous les cas possibles d’instructions. Cette organisation du code rend plus facile son remplacement par un JIT. Le patch d’Éric va permettre de remplacer chaque instruction du filtre BPF désiré par une séquence d’instructions x86. Le programme résultant, qui utilise une zone mémoire spéciale, est alors appelé pour analyser à pleine vitesse chaque paquet réseau.
Par défaut, ce compilateur JIT de BPF est désactivé, et il vous faudra faire un petit « echo 1 >/proc/sys/net/core/bpf_jit_enable », si vous voulez profiter de ses bienfaits. Précisons que l’implémentation, comme tout code en assembleur, est dépendante de l’architecture du processeur. Pour l’instant, seule l’architecture x86_64 est supportée par le compilateur JIT, mais il est possible (probable ?) que les futurs noyaux verront arriver un code gérant d’autres architectures.

Éric Dumazet a testé le gain potentiel qu’apporte son patch en regardant ce qui se passe quand tcpdump doit analyser dix millions de paquets UDP avec un filtre très basique (commande time /root/udpflood -f -l 10000000 10.2.2.1).
La machine est un quadri‐cœur Intel E5540 cadencé à 2,53 GHz, voici les temps obtenus :

sans tcpdump : 7,941 s ;
avec tcpdump, mais sans le JIT : 10,165 s ;
avec tcpdump et le JIT activé : 9,615 s.

On gagne donc 0,55 secondes sur un traitement de dix millions de paquets, ce qui se traduit par un gain d’environ 50 nanosecondes par paquet. Et encore, ce n’est que pour un filtre ultra-basique (voir l’e‐mail d’Éric), et les gains devraient être supérieurs quand la complexité du filtre augmente.
Éric Dumazet étant un très gros contributeur de la pile réseau du noyau Linux, j’ai profité de l’entrée de ce patch pour lui poser quelques questions (micro‐entretien datant du 14 juin dernier) :

LinuxFr.org : Bonjour Éric. J’ai vu que ton patch ajoutant un JIT pour BPF allait faire partie des nouveautés de la version 3.0, et je voudrais savoir si tu pouvais répondre à quelques questions pour les lecteurs de LinuxFr.

Éric Dumazet : Je suis à Toronto en ce moment pour la Netconf 2011, je profite d’une pause café pour te répondre. ;)

LinuxFr.org : Es-tu es le seul hacker du noyau chez SFR ? Es‐tu es payé à plein temps pour travailler sur la branche principale ?

Éric Dumazet : À ma connaissance je suis le seul « hacker chez SFR », mais je ne suis pas payé pour cela.
Je travaille chez SFR Business Team, Services Hébergés, pour des clients entreprise qui ont des problématiques générales, et il m’arrive d’utiliser mon expertise Linux dans des cas particuliers.

LinuxFr.org : C’est un peu surprenant que tu ne sois pas payé par SFR pour travailler sur le noyau. Pourtant quand on regarde les articles de statistiques de LWN ou de remword, on voit que tes patches sont portés au crédit de SFR.
Bizarre. Je me demande comment ils choisissent de compter les contributions des entreprises ?

Éric Dumazet : C’est très simple : quand un particulier a une adresse « générique », en @gmail.com, et qu’il contribue de façon significative à Linux, il reçoit un e‐mail lui demandant pour quelle entreprise il travaille. ;)
Il se trouve que je suis en effet un gros contributeur Linux, et donc j’ai eu des demandes pour préciser ce point. Par exemple, SFR finance mon déplacement à Toronto, donc mon employeur participe, lui aussi, à l’effort commun qu’est Linux. ;)

LinuxFr.org : Est‐il est prévu d’étendre le JIT pour d’autres architectures ? Serait‐ce facile à faire ?

Éric Dumazet : Pour le moment rien n’est prévu, mais ce serait assez simple. Il suffit d’une connaissance assez basique du jeu d’instructions du CPU, je dirais que quelques jours de travail par architecture devraient suffire. Il faut, bien entendu, une machine pour les tests, et un peu de savoir‐faire.

LinuxFr.org : Ce mécanisme de JIT n’est-il envisageable que pour BPF, ou bien est‐ce que cela aurait du sens de faire la même chose pour iptables ?

Éric Dumazet : J’ai l’intention de parler de ce sujet demain, justement. La boucle principale d’iptables peut en effet profiter du JIT, qui peut ensuite appeler des helpers externes (pour les matches ou targets qui contiennent du code qui ne nécessite pas de faire de l’inline).
Le gros intérêt de JIT pour iptables serait d’éviter d’avoir une copie de la table par CPU, comme c’est le cas actuellement, car le « code iptables » est mélangé avec les compteurs bytes/packets par règle.

LinuxFr.org : D’après les commentaires sur LWN, il semble que FreeBSD utilise une technique de JIT similaire pour BPF. Est‐ce que tu t’es inspiré de ça pour ton code ? De manière générale, est‐ce que tu regardes les systèmes BSD pour les comparer avec Linux ?

Éric Dumazet : Je suis au courant, mais je ne regarde pas le code de FreeBSD : je préfère que les développements Linux soient « self contained », pour éviter des contaminations pouvant poser problème de droits d’auteur.

LinuxFr.org : Sur quoi travailles‐tu pour les prochaines versions du noyau ?

Éric Dumazet : Je travaille actuellement (et de façon générale) sur des optimisations.
Par exemple, les prochaines machines pourront disposer de 40 cœurs et 80 threads, et des problèmes de contention surviennent souvent. Par exemple, cette semaine, j’ai proposé un patch qui améliore les performances sur une machine de ce type, dans un contexte « memcached » haute performance.
Ce patch a permis une augmentation d’au moins 200 % des performances sur un prototype d’Intel.

LinuxFr.org : Merci pour tes réponses, et merci surtout pour tes contributions au noyau.

En bref

Appel système sendmmsg

L’appel système classique recvmsg() permet de recevoir un message sur un socket réseau. Comme pour tous les syscalls, franchir la séparation entre espace utilisateur et espace noyau est une opération coûteuse, et les développeurs cherchent à optimiser cette opération. Dans le noyau 2.6.33, le développeur Arnaldo Carvalho de Melo a eu l’idée de créer un nouvel appel système (nommée recvmmsg()) permettant de recevoir plusieurs messages d’un seul coup, au lieu d’être limité à un unique message. Avec cette solution, on peut effectuer plus de travail à chaque franchissement de la barrière noyau-espace utilisateur.
Nous voyons maintenant arriver dans Linux 3.0 la contrepartie de ce patch, puisqu’Anton Blanchard a pris la peine d’écrire la même variante dopée aux stéroïdes de l’appel système sendmsg() habituel. Le nom est explicite et vous avez déjà compris que sendmsg() sert à envoyer des messages sur un socket réseau, au lieu d’en recevoir. Le nouveau noyau accueille donc le nouvel appel sendmmsg() qui n’est plus limité à l’envoi d’un seul message à la fois (mm, c’est pour multiple messages).
Cela permet de réduire les coûts des appels systèmes (syscall overhead), et le gain en performances est très notable, puisque, selon les tests d’Anton, on peut aller jusqu’à + 20 % de débit sur des paquets UDP et + 30 % sur des paquets bruts (raw socket).

Commande ping

Puisque nous sommes dans les paquets réseau, on peut noter que le noyau Linux 3.0 permet maintenant d’utiliser ping sans avoir les droits root. Il s’agissait à l’origine d’un patch implémenté par la distribution Openwall dans sa valeureuse quête d’un monde sans binaires à changement d’utilisateur setuid (set user id) dangereux. Selon Solar Designer, cet ajout est le résultat d’un examen attentif des alternatives et il a été finalement décidé que la meilleure solution était d’ajouter au noyau un nouveau type de socket nommé IPPROTO_ICMP.
Le nom est un peu trompeur, puisqu’il n’est pas question de prendre en charge tout le protocole ICMP. En réalité, le socket est extrêmement restreint et, dans cette implémentation, la seule chose qui peut passer, ce sont les messages de type ECHO (c’est‐à‐dire qu’il ne peut qu’envoyer des messages de type ICMP_ECHO et recevoir des réponses ICMP_ECHOREPLY).
Le patch de Vasiliy Kulikov (qui est un des résultats de l'initiative visant à renforcer la sécurité de Linux) détaille fort bien la problématique derrière cet ajout et indique que, pour des raisons de réduction de la surface d’attaque du noyau, cette option est désactivée par défaut.
Si une distribution choisit d’utiliser cette possibilité, alors, avec ce socket IPPROTO_ICMP et un binaire ping « patché » comme ici, il deviendra possible d’utiliser ping sans avoir des droits superutilisateur.
Hop, un binaire setuid de moins !

Pilotes graphiques

Dans le domaine des pilotes DRM du noyau, on note assez peu de changements en ce qui concerne Intel. Les nouveautés concernent essentiellement le cœur graphique des futures puces Ivy Bridge qui est d’ores et déjà supporté dans cette version Linux 3.0 (1 - 2). De la même manière, le PCH (Platform Controller Hub) de type Panther Point, le successeur des Cougar Point de l’architecture Nehalem, est lui aussi pris en charge par le noyau.
Le pilote spécifique destiné aux puces GMA500 (Poulsbo) continue d’être amélioré par Alan Cox. Cette fois, c’est son architecture même qui change, puisqu’il se base sur GEM et non plus sur TTM. Après cette réorganisation, Alan estime que le pilote GMA500 est d’une qualité suffisante pour quitter la branche staging dès le prochain noyau 3.1.
Côté AMD, c’est la nouvelle architecture Fusion de type Llano qui arrive dans cette version. On trouve également plusieurs patches écrits par Alex Deucher, afin de nettoyer le code et d’améliorer le support de la norme DisplayPort.
Enfin, en ce qui concerne le pilote Nouveau, on trouve le début du support de pmpeg sur les puces NV40 (série GeForce 6) et NV84/G84 (cela permet d’utiliser le cœur graphique pour le décodage des flux MPEG). Dave Airlie continue également de travailler sur la technologie Optimus, afin de pouvoir basculer entre une puce graphique intégrée et la carte graphique externe au processeur.

Ext4 creuse des trous

Dans sa version 2.6.38, le noyau Linux avait gagné la possibilité de « creuser des trous » au sein des fichiers (hole punching). Cette désallocation d’une partie de l’espace d’un fichier est utilisée dans divers scénario de virtualisation. Par exemple, au démarrage, un système hôte alloue un espace contigu à son système invité (guest) pour ensuite, en cas de besoin, récupérer les zones non utilisées au sein du fichier en faisant appel à FALLOC_FL_PUNCH_HOLE.
Alors que cette fonction n’était jusqu’à présent utilisable que sur les systèmes de fichiers XFS et OCFS2, le nouveau noyau 3.0 ajoute la compatibilité avec ext4. Les patches d’Allison Henderson (1 - 2 - 3 - 4 - 5) sont plus complexes que ce qui avait été initialement prévu, et il a fallu sept versions successives pour obtenir l’assentiment des sourcilleux gardiens du noyau. L’avantage, quand on se casse la tête et qu’on teste tout pour satisfaire un cerbère grognon, c’est que, par le plus bienheureux des hasards, on peut trouver des vieux bogues. Allison a pu ainsi ajouter à son tableau de chasse la correction d’une fonction qui s’est révélée donner de faux résultats et l’éradication d’un dangereux déréférencement de pointeur NULL.

Ordonnanceur réseau QFQ

Un nouvel algorithme d’ordonnancement des paquets réseau a été ajouté à la longue liste de ceux déjà présents dans le noyau Linux. Ces ordonnanceurs sont là pour implémenter une politique de traitement des paquets un peu plus subtile que le très bourrin premier‐arrivé‐premier‐servi (NET_SCH_FIFO).
On peut, par exemple, privilégier l’équité (Fair Queueing schedulers) entre les flots de paquets, mais cela se fait au détriment de la vitesse de traitement. On peut aussi choisir la rapidité (Priority based schedulers), mais alors la garantie de service ne s’appliquera qu’aux flots ayant la plus haute priorité, et les autres seront laissés pour compte.
Le petit nouveau se nomme « Quick Fair Queueing » et il ambitionne d’être équitable, tout en étant rapide. L’article des chercheurs italiens Fabio Checconi, Paolo Valente et Luigi Rizzo donne tous les détails sur ce nouvel algorithme et affirme qu’il est entre 2,5 et 3 fois plus rapide que les algorithmes existants qui ont les mêmes garanties de service.
C’est le développeur Stephen Hemminger qui, en se basant sur un code antérieur de Fabio Checconi, a écrit le patch qui est finalement entré dans le noyau 3.0.
À noter que l’ordonnanceur QFQ (NET_SCH_QFQ) est déjà présent dans le pare‐feu de FreeBSD nommé ipfw (voir la présentation issue de BSDCan2010).

Xen

Les derniers patches permettant au noyau Linux d’être parfaitement fonctionnel en mode Dom0 sous l’hyperviseur Xen ont été intégrés dans la branche principale.
Konrad Rzeszutek Wilk explique clairement sur son blog que cette intégration a été une tâche de très longue haleine. Xen a adopté une licence libre en 2002 et la première version publique est sortie en 2004, mais pendant des années les développeurs n’ont pas vraiment travaillé pour rejoindre la branche principale du noyau. La priorité était de fournir des offres commerciales en choisissant une certaine version du noyau, et en ne proposant qu’une compatibilité spécifique avec cette version. Si l’on ajoute le fait que les développeurs Linux poussaient les hauts cris en voyant le code de Xen et ne voulaient pas entendre parler d’un monstro‐patch, on comprend que la fusion dans la branche principale n’était pas à l’ordre du jour.
Au fil des années, les auteurs de Xen se sont quand même rendus compte que leur modèle devenait intenable et qu’ils passaient un temps infini à réadapter leur patch. Il valait mieux chercher à intégrer le noyau pour que cette compatibilité ne soit plus un problème. En plus, les développeurs Linux avaient intégré dès le 2.6.20 la machine virtuelle KVM, qui était reconnue comme étant beaucoup plus propre et simple. Cette concurrence de KVM (voir l’excellent article de Heise Online) a provoqué un déclin d’intérêt pour Xen, et ses développeurs ont décidé qu’il était devenu indispensable de finir l’intégration dans la branche principale.
Il leur a donc fallu accepter les critiques des mainteneurs Linux (corriger, entre autres, les monstrueux « #ifdef LINUX_VERSION_2_4_3 » ou « #ifdef LINUX_VERSION_2_6_18 » qui parsemaient le code) et aussi découper proprement leurs patches.
Le mode invité de Xen (DomU) a pu être intégré à partir du 2.6.23, mais il manquait encore le mode hôte (Dom0), et il a fallu continuer de corriger patiemment tous les défauts signalés sur la LKML.
Depuis la version 2.6.37, il est devenu possible de démarrer le système en Dom0 sous Xen, mais il manquait encore les indispensables pilotes génériques qui permettent à Xen de fonctionner réellement.
Le pilote réseau générique netback est entré dans le 2.6.39 et, finalement, le pilote générique en mode bloc rejoint la branche principale à l’occasion de cette version 3.0.
Les développeurs de Citrix ont alors pu pousser des cris de joie et célébrer dignement ce succès sur leurs blogs (1 - 2 - 3). La stratégie consistant à envoyer des patches courts, propres et pas trop invasifs a fini par payer.
Maintenant, il va falloir continuer le travail, puisque cette intégration s’est effectuée au prix d’une réduction des fonctions qui existent dans les produits commerciaux Xen (pas de mise en veille, par exemple, ni de flux USB envoyés aux systèmes invités).

SMEP

Dans le même esprit que le fameux bit NX (qui marque les pages accessibles en écriture, afin qu’elles ne soient pas exécutables), les futurs processeurs Intel auront un bit de sécurité nommé SMEP. Cette fonction « Supervisor Mode Execution Protection » (évoquée dans ce journal LinuxFr) va générer une erreur quand le noyau essaiera d’exécuter du code depuis une page marquée avec le bit user. Les patches du développeur Intel Fenghua Yu permettent d’activer ou de désactiver à volonté cette fonction pour les processeur ayant le drapeau X86_FEATURE_SMEP (il suffit de passer « nosmep » en paramètre lors de l’amorçage du système).
Le bit SMEP vise à rendre la vie plus difficile aux vils pirates informatiques qui parviennent à dévier le flux d’exécution du noyau vers une page en espace utilisateur contenant leur code de prise de contrôle (payload). Avec cette sécurité supplémentaire qu’offre SMEP, il ne sera plus possible d’exécuter ce code se trouvant en espace utilisateur.
Dan Rosenberg, spécialiste de la sécurité du noyau, explique bien sur son blog que SMEP reprend en partie les fonctions du module PAX_UDEREF, qui fait partie du patch « grsecurity/PaX ». Bien entendu, PAX_UDEREF utilise une autre technique — la segmentation — qui est purement logicielle. Cela veut dire qu’il y a un impact sur les performances et que le code n’est pas prêt de rentrer dans la branche principale, car il est très invasif. SMEP est un petit peu moins complet que PAX_UDEREF, mais le fait qu’il s’appuie sur une fonction intégrée dans les processeurs à venir lui permet d’être très simple et complètement transparent du point de vue des performances.

Namespace

Le patch d’Eric Biederman améliorant la gestion des espaces de nommage (name spaces) a été accepté dans le nouveau noyau. Ce travail vise à améliorer la gestion des conteneurs, c’est‐à‐dire des groupes de processus qui ont leur propre vue privée sur les ressources du noyau, le réseau ou bien encore les systèmes de fichiers.
D’habitude quand on parle de conteneurs, le problème consiste à les isoler au maximum, chacun dans son propre espace de nommage distinct. Pour ce patch, c’est le contraire, puisqu’Eric a créé un mécanisme pour permettre à d’autres processus, extérieurs au namespace du conteneur, d’interagir avec cet espace de noms.
Il a expliqué dans un e‐mail quelle utilité cela pouvait avoir ; par exemple, pour avoir des démons qui écoutent via des sockets dans plusieurs espaces de noms à la fois.
Pour cela, il est maintenant possible d’interagir avec un namespace particulier en le désignant via le fichier « /proc/self/ns » et en affectant un processus à un espace de noms avec l’appel setns().
Eric s’est prévalu de l’accord des développeurs travaillant sur les conteneurs et a expliqué que ses patches allaient faciliter leur travail en permettant une meilleure administration des espaces de noms.
La seule petite alerte s’est déroulée quand, le 21 juin dernier, Eric a envoyé à Linus une « demande de pull » pour corriger quelques erreurs dans son patch précédent. Comme l’objet du courriel était « nsfd fixes », Linus a été déconcerté et s’est demandé ce que venait faire le serveur NFS là‐dedans. Une fois le problème élucidé (il ne s’agissait pas de n*FSd mais bien de nSF*d comme dans Name Space File Descriptors), il a eu à endurer le courroux du mainteneur du noyau :

OK, c’est encore plus dingue que ce que je croyais.
Eric, merci d’arrêter d’utiliser des combinaisons aléatoires de lettres qui n’ont aucune signification pour personne à part toi. OK ?
Si tu ne veux pas te donner la peine d’écrire quelques lettres de plus et de rendre les choses lisibles, pourquoi est‐ce que tu devrais t’attendre à ce que les autres passent du temps à lire tes e‐mails ?

La contrition silencieuse étant l’une des meilleures défenses face à un Linus grognon, c’est la stratégie qu’a choisie Eric pour faire passer son patch.

Attributs étendus dans tmpfs

tmpfs (Temporary File System) est un système de fichiers particulier et simplifié qui n’existe que de façon temporaire en mémoire. Tout ce qui est stocké dessus disparaît lors d’un redémarrage de la machine. Fedora utilise par exemple intensivement tmpfs pour sa procédure de construction (build) de paquets RPM, et c’est à cette occasion qu’un souci est apparu. Depuis quelque temps, la tendance est d’utiliser les capacités POSIX sur les fichiers (POSIX file capabilities) pour augmenter la sécurité de certains paquets. Ces capacités reposent sur les attributs étendus (xattr) des systèmes de fichiers, puisque c’est là que sont stockées les capacités POSIX des fichiers. Les responsables Fedora ont donc simplement voulu introduire ces capacités sur les fichiers dans leur procédure de construction qui utilise tmpfs.
À ce stade, vous commencez certainement à soupçonner l’horrible vérité : tmpfs ne gère pas les attributs étendus, donc les capacités non plus, et par conséquent, il n’est pas possible de l’utiliser pour construire les paquets qui nécessitent ces capacités. Le drame…
Le développeur Eric Paris s’est donc retroussé les manches pour coder la gestion des attributs étendus nécessaires (uniquement ceux appartenant aux espaces de noms security.* et trusted.*) et a placer ça sous l’option de configuration CONFIG_TMPFS_XATTR.
À partir de ce noyau Linux 3.0, il est donc maintenant parfaitement possible de gérer les capacités POSIX sur un système de fichiers tmpfs, et les responsables du build de Fedora ont retrouvé la paix de l’esprit et la sérénité de l’âme.

Unification ARM

Le noyau Linux 3.0 intègre le tout début du travail visant à mieux unifier le code de l’architecture ARM.
Depuis la polémique et les menaces proférées par Linus en avril dernier, la décision a été prise de rationaliser le code de l’architecture ARM, qui était devenu un joyeux dépotoir. Les développeurs du marché de l’embarqué sont connus pour avoir des pratiques ~~sataniques perverses~~ différentes par rapport au reste de la communauté du noyau. Les variantes entre les plates‐formes sont légions, tandis que le délai avant la mise sur le marché (time to market) est un facteur absolument crucial. Cela implique que les « bonnes pratiques » de réutilisation du code et de factorisation des développements sont assez peu respectées, et que les doublons de pilotes prolifèrent. Après que Linus eut sifflé la fin de la récréation, il fut décidé de mettre en place une structure de données dédiée (un device tree) pour décrire chaque carte ARM et chaque SoC (système mono‐puce).
Les patches intégrés jusqu’à présent sont modestes (préparation du device tree 1 - 2 et regroupement du code 1 - 2 - 3), mais les prochains noyaux verront l’intégration du gros du travail.
En tout cas, les foudres torvaldiennes ont été détournées, puisque Linus a signalé dans son entretien avec Greg Kroah‐Hartman qu’il était content d’avoir gueulé un bon coup et de constater que cela avait porté ses fruits.

WoWLAN

Le « Wake on LAN » (WoL), c’est tout simplement la possibilité de réveiller son ordinateur à distance en lui envoyant un message spécifique via le réseau. C’est une fonctionnalité fort utile, puisqu’on peut ainsi économiser de l’énergie en laissant une machine distante profondément endormie en veille ACPI S3. Dès qu’on en a besoin, il suffit de lui envoyer le paquet magique (une trame Ethernet contenant « FF FF FF FF FF FF » suivi par seize répétitions de l’adresse MAC de l’ordinateur cible) pour qu’elle sorte de son sommeil, telle une Cendrillon moderne.
Dans cette nouvelle version 3.0, le noyau Linux offre une prise en charge basique de la nouvelle fonction WoWLAN dans la pile Wi‐Fi générique. Rien à voir avec World of Warcraft, puisqu’en réalité, le WoWLAN (Wake on Wireless LAN) fait la même chose que le « Wake on LAN » classique, mais sans les fils !
Les patches de Johannes Berg (1 - 2) introduisent plusieurs « déclencheurs » (triggers) pour le réveil, car un réseau sans fil est plus complexe qu’un classique réseau Ethernet. Outre le traditionnel réveil avec le paquet magique (NL80211_WOWLAN_TRIG_MAGIC_PKT), on peut aussi utiliser la fonction de réveil automatique en cas de déconnexion (NL80211_WOWLAN_TRIG_DISCONNECT) ou en cas d’envoi de plusieurs paquets selon un schéma bien spécifique (NL80211_WOWLAN_TRIG_PKT_PATTERN).

Pilote Kinect

Une version préliminaire d’un pilote Kinect a été intégrée dans le noyau 3.0 dans le sous‐répertoire « gspca » qui accueille les webcams.
Kinect est un périphérique construit par Microsoft et destiné à être utilisé en complément de la console de jeu Xbox_360. Il permet la détection des mouvements et offre donc une interaction qui n’est plus basée sur l’utilisation d’une manette de jeu, mais sur les gestes du joueur.
La détection visuelle s’effectue via deux capteurs complémentaires : un capteur CCD couleur classique et un capteur CMOS monochrome renforcé par un laser infrarouge. Le laser a une résolution très grossière, mais il est juste utilisé pour évaluer la profondeur de la scène (depth map).
Le pilote présent dans Linux 3.0 est écrit par Antonio Ospite qui s’est basé sur du code issu du projet OpenKinect. Il permet de gérer le flux vidéo du capteur CCD couleur, ainsi que le flux vidéo du capteur CMOS monochrome. En revanche, il ne permet pas encore de récupérer les informations venant du laser IR, et il est donc pour l’instant incapable de générer une depth map.
Les futures versions du noyau verront l’intégration des fonctions manquantes une fois que le code OpenKinect aura été suffisamment nettoyé et mis aux normes strictes de Linux.

Redémarrage et UEFI

Le noyau 3.0 embarque plusieurs modifications concernant le redémarrage du système et la compatibilité UEFI. C’est Matthew Garrett (alias mjg59) qui s’est attaché à revoir en détail ce code sensible, afin de minimiser les conséquences de l’incurie des constructeurs. Bien souvent, ces derniers ne testent que pour Windows, et un redémarrage effectué sous Linux risque de ne pas se dérouler correctement. Dans son patch, Matthew explique qu’il a réordonné la séquence de redémarrage afin qu’elle corresponde à l’ordre de Windows, et que cette modification corrige des soucis de redémarrage avec, par exemple, certains portables Thinkpad.
Dans sa courageuse quête, mjg59 s’est également plongé dans le monde merveilleux de la compatibilité UEFI. Vous connaissez sans doute cette norme d’Intel destinée à remplacer le bon vieux BIOS de nos machines… Mais connaissez‐vous l’origine du nom ?
Réponse de Matthew dans son commit Git :

UEFI veut dire « Unified Extensible Firmware Interface » et on peut l’interpréter ainsi : firmware est un ancien mot africain signifiant « Pourquoi faire un truc de qualité, quand on peut le faire tellement pourri que les enfants pleureront et que les adultes se recroquevilleront devant vous ? », tandis que UEI est la version celtique de « Le DOS nous manque, alors on l’a gravé dans votre ROM ».

Le nouveau noyau accueille plusieurs patches visant à corriger les dysfonctionnements d’une couche UEFI mal écrite par le constructeur de la carte mère. Auparavant, le code du noyau Linux s’en tenait strictement à la norme, mais il a fallu ajouter des rustine correctrices, car, pour reprendre encore une fois les mots de Matthew :

Nous avons été d’une naïveté charmante en croyant que la spécification avait une quelconque importance dans le monde réel.

Savoir si encore plus de patches vont être intégrés dans les futures versions est assez difficile à deviner. Linus Torvalds a l’air de penser qu’il faut se contenter d’interagir le moins possible avec UEFI. Quand mjg59 a suggéré qu’UEFI mangeait 1 Mio à l’amorçage et qu’il devrait être possible d’écrire des patches permettant de récupérer cette mémoire, Linus a été clair :

Peu importe si cette mémoire est difficile à récupérer. Nous n’avons qu’à la laisser où elle est. UEFI est une abomination aux yeux de Dieu, et je suis foutrement sûr que nous ne devrions pas nous mettre en quatre pour corriger toutes ses stupidités.
Putains de co#%ards qui croient que nous voulons une interface extensible, alors que ce que nous voulons c’est l’interface la plus réduite possible et pas cette folie qu’est UEFI !

Optimisations de perf

Le développeur Lin Ming, qui travaille chez Intel, a introduit une optimisation dans le code de l’outil de profilage perf. C’est la commande « perf probe » qui est concernée, celle qui permet d’insérer des sondes (kprobe) au sein du code noyau pour l’instrumenter et évaluer les flux de données. Le fonctionnement précédent pouvait être lent quand il s’agissait de retrouver les noms de fonctions à sonder. Le nouveau chemin rapide de recherche (fastpath) permet de retrouver le nom en interrogeant directement la section « debug_pubnames » du format DWARF.
Avant d’accepter le patch, Ingo Molnar, toujours curieux, a demandé une quantification du gain, pour voir si l’ajout de ce fastpath en valait la peine. Les résultats sont assez impressionnants, puisque Lin Ming a annoncé les chiffres suivants pour la fonction find_probes() dans son message de commit :

avant application du patch : 848 490 844 cycles pour 0,355 secondes ;
après application du patch : 205 684 469 cycles pour 0,086 secondes.

Compilation et Warnings

Pour les milliards de barbus parmi vous qui méprisent les paquets pré‐compilés de leur distribution et qui préfèrent se mitonner un noyau aux petits oignons, il est bon de savoir que le Makefile du noyau Linux 3.0 a été modifié par Sam Ravnborg.
Auparavant, les fous qui osaient passer l’option « W=1 » lors du build (pour pouvoir voir tous les warnings émis par GCC) étaient submergés par un tsunami d’alertes diverses et variées. C’est, certes, assez comique de lire qu’il y a eu 92 919 alertes lors de la compilation, mais le charme s’émousse très rapidement. Après tout, quand on passe « W=1 », c’est pour voir s’il n’y aurait pas quelque chose à corriger, alors il vaudrait mieux pouvoir filtrer les alertes non significatives et se concentrer sur les choses importantes.
C’est précisément l’objet du patch de Sam qui introduit une hiérarchie dans ce qui n’était auparavant qu’une soupe indifférenciée. Il y a maintenant trois niveaux différents qui donnent les résultats suivants :

avec « W=1 » : 4 859 alertes (les alertes qui pourraient éventuellement être importantes) ;
avec « W=2 » : 1 394 alertes (les alertes moins importantes) ;
avec « W=3 » : 86 666 alertes (les alertes ésotériques et probablement sans la moindre conséquence).

Le détail des options GCC de chaque niveau est visible ici. Sam Ravnborg a annoncé que son patch allait lui permettre de compiler systématiquement en mode « W=1 » et de creuser un peu les alertes, alors qu’avant il était découragé par le « bruit » que générait cette option.
Bien entendu, pour les masochistes nostalgiques, il est toujours possible de passer à « W=123 » pour retrouver le comportement précédent.

Belette strike back

Enfin, last but not least, avec ce passage en version 3.0, Linus a décidé qu’il était temps de changer également le nom par défaut du noyau. Après le célèbre « Flesh‐Eating Bats with Fangs » (Chauves‐souris mangeuses de chair avec des crocs) du noyau 2.6.36, il va maintenant falloir s’habituer à « Sneaky Weasel » (Belette sournoise) comme nom de code de Linux 3.0.
Cette bestiole est effectivement d’une sournoiserie peu commune, puisque c’est la seconde fois qu’elle fait son apparition, après la peu ragoûtante « Pink Farting Weasel » (Belette rose péteuse) du 2.6.23-rc4.

Statistiques et regard rétrospectif sur la série 2.6.x

Avec le passage à Linux 3.0, c’est une page de l’histoire du noyau qui se tourne.
Certes, ce changement de numérotation a été effectué uniquement pour simplifier les choses. Certes, le préfixe 2.6 n’avait plus guère de sens. Certes, le mode de développement de Linux reste ce qu’il était auparavant, et aucune technique révolutionnaire n’est intégrée. Il n’empêche que le passage à la version 3.0 est symbolique, et que cela représente une occasion de se retourner et de mesurer le chemin parcouru.

En ce qui concerne le cycle particulier du noyau 3.0, il faut bien dire qu’il n’a pas grand chose de remarquable. Boring à souhait, comme les aime Linus. Tout juste un peu plus calme que d’habitude, puisqu’on compte un peu plus de 9 000 patches écrits par 1 110 développeurs, pour un gain net d’environ 113 000 lignes de code dans l’arbre des sources. La seule spécificité un peu notable de ce cycle est le fait que le développeur le plus prolifique s’avère être employé par Microsoft : K. Y. Srinivasan a posté sur la LKML pas moins de 343 patches de nettoyage et de correction du pilote de virtualisation Hyper-V !
Comme le souligne avec un brin de perfidie Jonathan Corbet : « C’est impressionnant de voir combien de patches sont nécessaires pour nettoyer un pilote qui fait moins de 15 000 lignes de code. »
Même si la métrique du nombre de patches est criticable, j’ajouterais que le pilote Hyper-V de Microsoft, au moment de rentrer dans la branche staging en 2009, avait déjà subi une vigoureuse phase de nettoyage de plus de 200 patches écrits par Greg Kroah‐Hartman pour le rendre conforme au style de codage Linux.

Toujours est‐il que, pour ce cycle, la conséquence de cette incongruité statistique, c’est qu’en termes de patches, Microsoft apparaît en cinquième position des firmes ayant contribué à ce noyau Linux 3.0.
Toutefois, l’honneur est sauf, puisque Red Hat, Intel, Novell et IBM restent devant. :-)

Si l’on prend un peu de recul et qu’on regarde les statistiques de la série complète des 2.6.x, alors les chiffres deviennent plus intéressants. En lisant le document ODS de statistiques globales réalisé par Greg Kroah‐Hartman, on peut mieux se rendre compte de l’évolution quantitative qui s’est déroulée durant cette période.
La sortie officielle du noyau 2.6.0 a été annoncée par Linus le 18 décembre 2003. À cette époque lointaine et héroïque, il y avait dans l’arbre des sources seulement 15 007 fichiers pour un total de 5 929 913 lignes. Le noyau 2.6.39, dernier représentant de la glorieuse série des 2.6.x, est apparu sur les serveurs de kernel.org le 18 mai 2011. Ce beau bébé faisait 14 533 662 lignes réparties dans 36 706 fichiers.
En près de sept ans et demi, le noyau Linux a donc plus que doublé le nombre de ses fichiers (× 2,44), et il a également plus que doublé le nombre de ses lignes de code (× 2,45).
Et encore, ces chiffres émanent du document de Greg et ne prennent pas en compte le cycle du noyau 3.0, ni même les nombreux noyaux 2.5.x qui peuvent être considérés comme des versions candidates du 2.6.0. Si l’on adopte ce point de vue, plus large que la stricte limitation aux noyaux ayant le préfixe 2.6.x, alors les statistiques sont encore plus frappantes : 291 664 patches contribués par 8 078 développeurs différents et, en 9 ans et demi, un ajout d’environ 10,5 millions de lignes de code par rapport au noyau 2.4 !

Ces chiffres reflètent l’incroyable succès du modèle de développement progressivement choisi pour le noyau Linux dans la série 2.6.x. Le remplacement des simples courriels envoyés à Linus par l’utilisation de BitKeeper, puis de Git. La fin des version quasi‐figées, comme le 2.4.x, et le choix d’une progression rapide, avec des nouvelles versions stables qui sortent tous les trois mois. Tout ceci fonctionne très bien et représente un grand progrès par rapport au modèle précédent.
Au fil des années, le processus s’est même affiné : nous avons maintenant des versions spécifiques du noyau qui sont maintenues à long terme, la fameuse branche stable de Greg Kroah‐Hartman. Pour résoudre le problème récurrent des pilotes qui vivent en dehors de la mainline, la solution d’une antichambre spéciale a été retenue : c’est la fameuse branche staging, qui est également maintenue par Greg Kroah‐Hartman.

Tiens, je m’aperçois qu’entre son document ODS de statistiques et ses diverses tâches de mainteneur, on retrouve souvent le nom de Greg Kroah‐Hartman dans ce texte. Afin de finir dignement cette dépêche, pourquoi ne pas en profiter pour lui poser quelques questions ? Après tout, il fait partie des chevaliers de la table ronde de Linux, puisqu’il a été identifié dans un article de LWN comme étant l’un des très rares contributeurs ayant envoyé au moins un patch dans chaque version depuis le 2.6.0.
Mais un pico‐entretien alors, parce que Greg a une charge de travail absolument colossale !

LinuxFr.org : Bonjour Greg. J’écris un article sur le noyau pour le site LinuxFr.org. Est‐ce que tu es OK pour que je t’interroge rapidement au sujet du modèle de développement ?

Greg Kroah‐Hartman : Tu peux toujours poser tes questions, n’hésite pas.

LinuxFr.org : De nos jours, avec la puissance de Git, cela semble incroyable que les anciennes versions du noyau aient pu sortir sans aucun gestionnaire de code. Comment était‐ce à l’époque ? Est‐ce que tu peux décrire cet âge des ténèbres du noyau ?

Greg K‐H : Ce n’était pas du tout « l’âge des ténèbres », et ce mode de développement marchait très correctement. C’est juste qu’à l’époque nous ne réalisions pas que nous aurions pu aller encore plus vite que ce que nous faisions alors. :)

LinuxFr.org : Est‐ce que tu peux nous décrire la situation actuelle du Linux Driver Project que tu as créé ? Est‐ce que c’est un succès ?

Greg K‐H : Je pense que c’est un succès du fait qu’il n’existe pas, à l’heure actuelle et à ma connaissance, de périphérique sans pilote Linux. Il s’est avéré que nous n’avions pas réellement de nouveaux pilotes à écrire pour ce projet, juste des tonnes de pilotes qui existaient en dehors de la branche principale et que nous devions intégrer proprement. Donc, nous avons réorienté notre effort vers la partie staging, qui contient les pilotes qui n’ont pas la qualité « normale » des autres parties du noyau. Ils restent là, et après qu’ils ont été nettoyés, ils peuvent enfin migrer vers leur « vraie » section dans le noyau. Si tu regardes l’effort de développement qui est consacré à cette portion du noyau, tu verras à quel point c’est actif (des milliers de patches par version).

LinuxFr.org : Si tu devais résumer tout le cycle 2.6.x, que dirais‐tu ? Quelle est la principale réussite ?

Greg K‐H : Tu veux que je te résume huit années en quelques phrases ? Eh, désolé, mais ça ne va pas être possible. :)
Que penses‐tu de : « Nous faisons maintenant des sorties à périodicité fixe, avec un nouveau noyau stable tous les trois mois, et nous avons une procédure en place pour assurer le maintien des vieux noyaux, tandis que le nouveau est développé en vue de la prochaine version. » ?
En résumé, notre modèle de développement est bien meilleur maintenant, notre rythme d’intégration des changements est incroyable et nous continuons à augmenter le nombre de contributeurs à chaque version.

LinuxFr.org : Après Git, après la branche staging, quelle est la prochaine étape pour encore améliorer le mode de développement du noyau ?

Greg K‐H : Qu’est‐ce qui ne va pas dans notre mode de développement actuel et qui a besoin d’être amélioré ? Sérieusement, j’aimerais le savoir. Nous évaluons en permanence notre façon de travailler et nous faisons des changements en fonction des problèmes que nous rencontrons.

LinuxFr.org : En dépit des réussites du cycle 2.6.x, les systèmes à base de noyau Linux n’ont pas percé sur le bureau. Est‐ce que la communauté de développement du noyau peut y faire quelque chose, ou bien est‐ce une question qui relève essentiellement de l’espace utilisateur ?

Greg K‐H : C’est essentiellement un problème lié aux constructeurs. À part quelques exceptions, ils ne veulent pas fournir Linux sur leurs machines pour leurs clients, et cela pour des raisons économiques plutôt valables.
Cela va simplement prendre du temps, mais je ne suis pas inquiet, nous ne sommes pas près de disparaître. :)

LinuxFr.org : Pour finir, une question personnelle. Tu es le mainteneur du sous‐système USB, du sous‐système « driver core », de sysfs, etc.. Tu es aussi responsable de la série stable et de la branche staging. Tu donnes de nombreuses conférences sur le noyau. Comment est‐il possible de faire face à autant de tâches à la fois ?

Greg K‐H : Oh, n’oublie pas que j’ai aussi un vrai travail à faire en même temps. :)
Je ne sais pas comment c’est possible. Une bonne gestion du temps peut‐être ? Est‐ce qu’un oiseau peut expliquer aux autres comment il est possible de voler ? C’est juste une réponse naturelle à ce qu’il a besoin de faire.

LinuxFr.org : OK Greg, merci pour tes réponses et bon vol pour toi et pour les noyaux 3.x. ;-)

Aller plus loin

[LWN 1] Les nouveautés du noyau 3.0 (2812 clics)
[LWN 2] Les nouveautés du noyau 3.0 (943 clics)
Les articles récapitulatifs de h-online.com (268 clics)
Liste des nouveautés sur kernelnewbies.org (749 clics)

# Les pages propres

Posté par ymorin le 22 juillet 2011 à 08:23. Évalué à 5.

Quand la pression mémoire est trop importante, alors les pages en statut « clean » peuvent être « enlevées » de la mémoire physique. Ce mécanisme d’éviction (memory reclaiming) va enregistrer les pages dans leur espace de stockage particulier. Cet espace, nommé backing store, c’est tout simplement le disque ou la partition d’échange (swap) de la machine.

Je ne suis pas sur de ceci...
Justement, si les pages sont clean, c'est que leur contenu n'a pas changé par rapport au backingstore (le disque, quoi...). Donc on peut simplement les virer de la RAM sans état d'âme.

Le prochaine accès à une telle page provoquera un major pagefault, et le noyau va aller la rechercher depuis le disque.

Les pages dirty, quant à elles, sont en effet ré-écrite sur le HDD.

Les deux cas ci-dessus, c'est pour les pages qui sont créées à cause de la lecture d'un fichier. Par contre, les pages qui n'ont pas de correspondance avec un fichier, comme les pages obtenues avec un malloc(), sont en effet envoyées dans le swap.

Maintenant, il est aussi possible d'utiliser le swap pour stocker des pages qui sont clean, si le swap est plus rapide que le disque d'où vient la page, ou si elle vient du réseau.

Bon, je vais finir la lecture...

Hop,
Moi.
- [^] # Re: Les pages propres
  
  Posté par Kerro le 22 juillet 2011 à 23:56. Évalué à 6.
  
  Le prochaine accès à une telle page provoquera un major pagefault, et le noyau va aller la rechercher depuis le disque.
  
  C'est justement le but de la manœuvre: ne pas avoir besoin de les récupérer sur le disque.
  
  J'en reviens toujours à une vieille idée: pourquoi ne pas avoir un périphérique avec une tonne de RAM lente ?
  Admettons que la RAM 4 fois plus lente coûte 4 fois moins cher (à vue de nez, c'est le cas). Pour 20 € j'ai 4 Go en plus. Et ajoutons 10 € pour l'électronique. Plus lent que la RAM principale, mais bien plus rapide que le disque.
  - [^] # Re: Les pages propres
    
    Posté par ymorin le 23 juillet 2011 à 00:39. Évalué à 8.
    Le prochaine accès à une telle page provoquera un major pagefault, et le noyau va aller la rechercher depuis le disque.
    
    C'est justement le but de la manœuvre: ne pas avoir besoin de les récupérer sur le disque.
    
    Tout à fait d'accord. Mais ce n'est ce sur quoi je réagissait. patrick_g a dit :
    
    les pages en statut « clean » peuvent être « enlevées » de la mémoire physique. Ce mécanisme d’éviction (memory reclaiming) va enregistrer les pages dans leur espace de stockage particulier.
    
    Or, une page clean n'est pas enregistrées sur le disque. Son entrée dans la page table est simplement suprimée, et la RAM qu'elle utilisait est de suite disponible pour y mettre une autre page (du même processus, ou d'un autre).
    
    Seules les pages dirty sont écrites sur le disque.
    
    Maintenant, ce nouveau mécanisme ajoute une étape intermédiaire : plutôt que de trasher la page, elle est envoyée au cleancache qui va la stocker temporairement au cas où elle serait demandée dans pas longtemps . Ce stockage peut alors être effectué de différentes manières :
    - la page est envoyée au swap
      ça ne change rien par rapport à avant
    - la page est compressée en RAM
      cleancache va stocker plusieurs pages compressées en utilisant moins de pages au total
      
      ça reviens un peu à un truc qui existait il y a 15 ans sous Win3.11 qui faisait exactement ça; enfin, qui essayait... ;-)
    - la page est compressée en RAM, puis envoyée au swap
      l'échange vers/depuis le swap est plus rapide
      
      la page est toujours en RAM
      
      si la pression est vraiment trop forte, on vire la page de la RAM plus tard
    - la pages est envoyée sur un périphérique bloc très rapide (eg. SSD)
      un peu comme si c'était un swap
      
      si ce périphérique se remplit trop, la page est migrée vers le vrai swap
    Attention ! Ces possibilités ne sont pas (toutes) disponibles dans le 3.0. cleancache propose juste une infrastructure générique pour y brancher différentes politiques de gestions des pages.
    
    pourquoi ne pas avoir un périphérique avec une tonne de RAM lente ?
    
    C'est pas faux ! ;-)
    
    Cette RAM jouerai le même rôle envers les disques que le cache envers la RAM. Une espèce de cache, sauf qu'au lieu d'être entre le processor et la RAM, il serait entre la RAM et le disque, en quelque sorte...
    
    Maintenant, faire un tel truc ne devrait pas être ultra complexe. Il faudrait:
    - un contrôleur SATA-3 esclave
    - un paquet de barettes de RAM
    - quelques petits composants par-ci par-là
    - et une petite batterie en case de coupure de courant
    Bon, je te rassure, ça existe :
    Hop,
    Moi.
    - [^] # Re: Les pages propres
      
      Posté par ymorin le 23 juillet 2011 à 00:41. Évalué à 1.
      un contrôleur SATA-3 esclave
      
      Ou plutôt un contrôleur PCI express, 8x ou 16x tant qu'à faire... ;-)
  - [^] # Re: Les pages propres
    
    Posté par Nicolas Boulay (site web personnel) le 23 juillet 2011 à 17:50. Évalué à 4.
    
    Cela existe dejà. Il y a eu des ram disque à base de DRAM.
    
    Le problème est en général la gestion de tous les fils de connections : il est difficile de mettre plus de 2 puces sur le même bus, cela coute donc une fortune en IO.
    
    Une puce DRAM coute 2 à 10$, pour qu'un disque de DRAM soit plus rentable que la RAM classique, il faut pouvoir gérer plus de puces,ce n'est pas évident du tout.
    
    "La première sécurité est la liberté"
    - [^] # Re: Les pages propres
      
      Posté par Guillaume Knispel le 25 juillet 2011 à 21:12. Évalué à 1.
      
      on peut les chaîner, mais je me demande si rambus n'a pas breveté le concept
      - [^] # Re: Les pages propres
        
        Posté par Nicolas Boulay (site web personnel) le 26 juillet 2011 à 13:46. Évalué à 1.
        
        non, on ne peut pas chainer de la DDRAM, de la rambus oui, c'est le principe de leur bus point à point.
        
        "La première sécurité est la liberté"
# super-extra-lucide

Posté par sebas le 22 juillet 2011 à 08:44. Évalué à 6.

tirer un coup de chapeau aux 176 extralucides du sondage LinuxFr de janvier 2010 qui avaient deviné que ce noyau 3.0 sortirait cette année

... et surtout à leur grand-gourou, Cilyan Olowen, qui a su en deviner la raison (avec une marge d'erreur d'une seule version) ;-) :

Re: Quelle serait LA nouveauté qui nécessiterait un changement aussi profo (Posté par Cilyan Olowen)
La fin du verrou global ?
C'est pour ça que j'ai voté 2011 (je suis optimiste !)
# Arbre B et B+

Posté par Miguel Moquillon (site web personnel) le 22 juillet 2011 à 08:59. Évalué à 10.

J'adore tes dépêches patrick_g. Elles sont d'une qualité exemplaire.

Je voudrais ici juste corriger un détail. Les arbres B sont, en français, les arbres équilibrés (le B signifiant balanced); il en existe plusieurs types dont les plus connus sont les arbres rouges et noirs, et les arbres binaires. Dans les arbres équilibrés (B Tree), les feuilles ne sont pas reliées entre elles. Ce sont avec les B+ Tree que les feuilles sont reliées entre elles ; c'est ce qu'utilise par exemple ReiserFS. Il existe aussi les B* Tree qui sont des arbres qui optimisent la densité des nœuds internes (il fortifie l'équilibre de ces derniers).

Voilà c'est tout.
- [^] # Re: Arbre B et B+
  
  Posté par patrick_g (site web personnel) le 22 juillet 2011 à 09:13. Évalué à 8.
  
  dans les arbres équilibrés (B Tree), les feuilles ne sont pas reliées entre elles
  
  Tu es sûr ?
  Dans l'article de Valerie Aurora il y a pourtant cette phrase : "To start with, btrees in their native form are wildly incompatible with COW. The leaves of the tree are linked together"
  
  Et celle-ci : "Rodeh's btrees are different: first, he got rid of the links between leaves of the tree (...) This is a fairly standard form of btrees in file systems, sometimes called B+trees".
  - [^] # Re: Arbre B et B+
    
    Posté par Miguel Moquillon (site web personnel) le 22 juillet 2011 à 10:05. Évalué à 10.
    
    Oui, pour avoir travaillé dessus il y a quelques années, je suis sûr. Pour les propos de Valérie Aurora, il est commun d'appeler les arbres B+-Tree tout simplement B-Tree puisqu'ils sont sont aussi des B-Tree (une famille particulière des B-Tree très en vogue dans les systèmes de fichiers). Par contre, les propos de Rodeh me laissent perplexe; il s'est peut-être mélangé les pinceaux dans son écrit.
    
    Il suffit aussi de vérifier sur wikipédia :
    http://en.wikipedia.org/wiki/B-tree
    http://en.wikipedia.org/wiki/B%2B_tree
    
    Il y a aussi suffisamment d'articles sur le sujet sur le Web (deux articles en première page de Google):
    http://www.bluerwhite.org/btree/
    http://www.mec.ac.in/resources/notes/notes/ds/bplus.htm
- [^] # Re: Arbre B et B+
  
  Posté par Alex G. le 22 juillet 2011 à 11:09. Évalué à 4.
  
  Tant qu'on parle de ça je voulais savoir si cette compatibilité de B+ et COW n'était pas la base théorique de CouchDB ? Quelle est la différence sinon ?
  - [^] # Re: Arbre B et B+
    
    Posté par Miguel Moquillon (site web personnel) le 22 juillet 2011 à 15:30. Évalué à 2.
    
    Intéressant. J'ignorais que CouchDB se basait sur un COW B-Tree.
    C'est bizarre qu'ils n'en parlent pas ici http://guide.couchdb.org/draft/btree.html
- [^] # Re: Arbre B et B+
  
  Posté par fmaz fmaz le 22 juillet 2011 à 11:58. Évalué à 10.
  
  Je vais faire mon pinailleur mais les arbres rouge/noir ne sont pas des b-tree.
  
  Dans un b-arbre, toutes les feuilles ont la même profondeur. En revanche, les nœuds ont un nombre variable de fils.
  
  Dans un arbre binaire de recherche, tous les nœuds internes ont exactement deux fils mais les feuilles n'ont pas la même profondeur.
  
  Les arbres rouge/noir sont des arbres binaires de recherche qui codent certaines classes de b-arbres (les 2-4 arbres).
  
  Pour répondre à patrickg, les arbres binaires de recherche et les b-arbres de base sont des _dictionnaires. On veut pouvoir chercher, ajouter et retirer des éléments identifiés par une clef. Dans ces implémentations, les feuilles ne sont pas liées entre elles.
  
  Mais on peut aussi vouloir faire des choses supplémentaires comme accéder efficacement
  - au k-ième élément ;
  - à un élément médiant ;
  - à l'élément immédiatement après ou avant un élément donné.
  
  Pour cela, on enrichi la structure et notamment pour accéder au prédécesseur ou au suivant, on relie les feuilles entre elles.
  - [^] # Re: Arbre B et B+
    
    Posté par Miguel Moquillon (site web personnel) le 22 juillet 2011 à 15:24. Évalué à 6.
    
    Oui, tu fais bien d'être pinailleur parce que tu as raison. J'ai été effectivement un peu rapide en généralisant les arbres rouge et noir d'arbre équilibrés.
# +1

Posté par B16F4RV4RD1N le 22 juillet 2011 à 09:16. Évalué à -7.

Moi j'attends avec impatience le noyau 4.0, qui devrait peut-être sortir d'ici 2 ou 3 mois, en même temps que firefox 17 ou FreeBSD 12 ;)

En tout cas, on ne peut pas dire que Linux fasse la course au numéro de version contrairement à d'autres ;) (mais pour les BSD ça va encore)

C'était mon commentaire inutile du jour, ayant raté le preum's...

Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
- [^] # Re: +1
  
  Posté par jihele le 22 juillet 2011 à 09:55. Évalué à 10.
  
  Je connais un autre OS qui en est déjà à la v7 et on attend toujours la version stable.
  - [^] # Re: +1
    
    Posté par 🚲 Tanguy Ortolo (site web personnel) le 22 juillet 2011 à 11:57. Évalué à 10.
    
    Non, ça c'est le nom commercial, en fait c'est la 6.1.
  - [^] # Re: +1
    
    Posté par swap38 (site web personnel) le 22 juillet 2011 à 11:59. Évalué à 6.
    
    En réalité, même si le nom commercial est "seven" (qui-n'a-rien-a-voir-avec-la-version-6.0-que-tout-le-monde-a-trouvé-pourrie), il s'agit en fait de la version ... 6.1 !
    
    Démarrer > cmd > ver
    
    Mais chut ! c'est un secret ;)
    
    Sondage : quel sera le numéro commercial de la vraie version 7.0 ?
    (8 ? 6+9=15 ? 2017 ? ...)
# Excellente présentation

Posté par Razique le 22 juillet 2011 à 09:51. Évalué à 8.

A chaque fois, c'est un plaisir de lire les présentations de noyau, le contenu est de qualité,
merci :)
# Ah ces noms !

Posté par Olivier Esver (site web personnel) le 22 juillet 2011 à 10:00. Évalué à 10.

Bientôt quand on me demandera quel OS j'ai je pourrai dire : j'ai Ocelot onirique avec un noyau Belette sournoise.

S'il y a un problème, il y a une solution; s'il n'y a pas de solution, c'est qu'il n'y a pas de problème.
- [^] # Re: Ah ces noms !
  
  Posté par liberforce (site web personnel) le 22 juillet 2011 à 15:03. Évalué à 8.
  
  J'ai presque envie de downgrader mon noyau pour faire tourner "belette rose péteuse" :-p
  - [^] # Re: Ah ces noms !
    
    Posté par JoeltheLion (site web personnel) le 25 juillet 2011 à 13:52. Évalué à 2.
    
    Je crois qu'une meilleure traduction serait "belette pétant du rose", ce qui n'est pas mal non plus, il faut l'avouer!
# Petite coquille

Posté par pamputt le 22 juillet 2011 à 10:49. Évalué à 3.

Merci pour cette excellente dépêche. Je tenais juste à signaler une petite coquille
> Selon Josef Bacik, cet outil est déjà écrit et il est en phase de de vérification intensive
à la fin de la section Amélioration de Btrfs
- [^] # Re: Petite coquille
  
  Posté par patrick_g (site web personnel) le 22 juillet 2011 à 10:58. Évalué à 3.
  
  Corrigé. Merci de l'avoir signalé.
- [^] # Re: Petite coquille
  
  Posté par Naha (site web personnel) le 24 juillet 2011 à 23:37. Évalué à 1.
  
  Il y a aussi « les volumes sauvegardées » –> sauvegardés.
  - [^] # Re: Petite coquille
    
    Posté par patrick_g (site web personnel) le 25 juillet 2011 à 06:39. Évalué à 2.
    
    Oui bien vu. C'est corrigé.
- [^] # Re: Petite coquille
  
  Posté par ziliss le 25 juillet 2011 à 09:48. Évalué à 1.
  
  Il y a aussi 3 fois le mot DRM à la place de DRI (Direct rendering infrastructure).
  - [^] # Re: Petite coquille
    
    Posté par patrick_g (site web personnel) le 25 juillet 2011 à 10:18. Évalué à 5.
    
    http://en.wikipedia.org/wiki/Direct_Rendering_Manager
    - [^] # Re: Petite coquille
      
      Posté par ziliss le 25 juillet 2011 à 20:16. Évalué à 3.
      
      Merci, je ne connaissais pas.
      Alors il faut faire pointer les liens de 2 "DRM" vers http://en.wikipedia.org/wiki/Direct_Rendering_Manager
# À Perrault

Posté par Alex G. le 22 juillet 2011 à 11:01. Évalué à 10.

pour qu’elle sorte de son sommeil, telle une Cendrillon moderne.

Hem ! Je crois qu'il y a une petite confusion entre la Belle au bois dormant et Cendrillon :-)
- [^] # Re: À Perrault
  
  Posté par patrick_g (site web personnel) le 22 juillet 2011 à 11:43. Évalué à 3.
  
  Oui effectivement y'a eu boulette ;-)
  Je le laisse tel quel parce que ce n'est pas une faute d'orthographe ou de grammaire.
  - [^] # Re: À Perrault
    
    Posté par B16F4RV4RD1N le 22 juillet 2011 à 16:28. Évalué à 10.
    
    Une Cendrillon moderne, bien entendu prolétarienne et injustement spoliée par ses soeurs capitalistes oisives, « sortira de son sommeil » en brisant les chaînes de son prolétariat et en utilisant un OS de communistes comme Linux.
    
    Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
    - [^] # Re: À Perrault
      
      Posté par Arkem le 23 juillet 2011 à 13:48. Évalué à 6.
      
      La version ancienne, c'est quand elle épousait un aristocrate?
# Ecoutons le noyau!

Posté par Frederic Cambus (site web personnel) le 22 juillet 2011 à 11:16. Évalué à 10.

Pouvais-t-on rêver plus belle journée pour une mise à jour des sources de Linux Radio? http://www.linux.fm

Ah, Hash Include... Slash Asterisk...

Ecoutons le noyau, il a beaucoup à nous apprendre!
- [^] # Re: Ecoutons le noyau!
  
  Posté par Grunt le 23 juillet 2011 à 00:09. Évalué à 5.
  
  Dommage le Flash (mais les lien vers les MP3 sont dispos dans le code source de la page).
  
  Ceci dit, c'est à ma connaissance la seule webradio qui ne diffuse que du contenu 100 libre sans clause non-commerciale.
  
  Ben oui, ce flux audio est une oeuvre dérivée du code source du noyau, donc sous GPLv2 :P
  
  THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
# SMEP et la segmentation

Posté par reno le 22 juillet 2011 à 11:18. Évalué à 3.

Tout d'abord un grand merci pour cette dépêche.

Juste une petite note: tu notes qu'il était possible d'avoir l'équivalent de la fonctionnalité de SMEP grâce à la segmentation, cependant la segmentation n'est disponible qu'en mode 32bit pour les x86: AMD l'a retiré dans le mode 64bit,
dommage pour une fois que les x86 avaient une fonctionnalité intéressante (pour la sécurité)..

A quand un CPU ayant des pointeurs 96 bits (64bit d'adressage et 32bit de segments)?
Ça rendrait très difficile l'exploitation de débordement de tampons!
- [^] # Re: SMEP et la segmentation
  
  Posté par Nicolas Boulay (site web personnel) le 22 juillet 2011 à 12:03. Évalué à 6.
  
  Les segments sont utilisé par personne. Je crois que les segments étaient utilisés par pax surtout car il contenait un bit de sécurité non présent dans les pages. Si le bit est ajouté, cela baisse encore l’intérêt des segments.
  
  "La première sécurité est la liberté"
  - [^] # Re: SMEP et la segmentation
    
    Posté par reno le 22 juillet 2011 à 14:12. Évalué à 3.
    
    Les segments sont utilisé par personne.
    
    Oui, c'est un très bon argument: on voit bien que la sécurité actuelle est parfaite donc ne changeons rien! ;-)
    Sinon un article qui parle des segments et de leur intérêt pour la sécurité (note que l'implémentation des segments pour le x86 est différente):
    http://www.ai.mit.edu/projects/aries/Documents/Memos/ARIES-02.pdf
    - [^] # Re: SMEP et la segmentation
      
      Posté par Nicolas Boulay (site web personnel) le 22 juillet 2011 à 14:46. Évalué à 5.
      
      J'ai pas le temps de tout lire ton lien, mais basiquement les segments sont des pages de tailles variables. C'est tellement complexe à gérer d'un point de vue hardware, qu'ils sont en nombre limité par processus.
      
      C'est beaucoup plus simple d'ajouter des flags aux pages actuelles (bit execute user/root par exemple, on pourrait aussi avoir des rings pour séparer les données et le code d'une application, entre une partie sensible et le reste, cela serait plus efficace mais pas plus sécurisé que 2 processus).
      
      "La première sécurité est la liberté"
- [^] # Re: SMEP et la segmentation
  
  Posté par gato le 23 juillet 2011 à 20:55. Évalué à 0.
  
  Si je ne m'abuse, sur les x86_64 seuls les 48 premiers bits sont utilisés pour les adresses, ce qui laisse 16 bits disponibles. Est-ce que le bit SMEP est de ceux-là ?
  - [^] # Re: SMEP et la segmentation
    
    Posté par Antoine le 24 juillet 2011 à 03:57. Évalué à 3.
    
    Les bits en question ne se situent pas dans les adresses virtuelles mais dans les tables arborescentes de traduction d'adresses (page tables). Or celles-ci n'ont pas besoin de stocker tous les bits des adresses physiques représentées, seulement ceux qui sont susceptibles d'être impactés par le mécanisme de traduction d'adresse.
- [^] # Re: SMEP et la segmentation
  
  Posté par dominique dechamps le 02 août 2011 à 14:32. Évalué à 2.
  
  Multics le retour ?
  
  SMEP me rappelle les anneaux de Multics
  http://en.wikipedia.org/wiki/Ring_%28computer_security%29
  
  "A quand un CPU ayant des pointeurs 96 bits (64bit d'adressage et 32bit de segments)?"
  ça s'appellait un mainframe ...
  
  La roue tourne et on la réinvente !
  - [^] # Re: SMEP et la segmentation
    
    Posté par reno le 03 août 2011 à 09:33. Évalué à 2.
    
    Bin non justement dans ce cas présent, il est peu probable que la roue soit réinventée ce qui est dommage car les fabriquants de CPU ajoutent des millions de transistors pour gagner 0.0001% en performance, mais rien pour:
    -détecter les débordements d'entier sauf si on a la chance d'avoir un MIPS.
    -empêcher les écrasements de buffer..
    - [^] # Re: SMEP et la segmentation
      
      Posté par dominique dechamps le 04 août 2011 à 00:40. Évalué à 3.
      
      Et pourtant
      
      "les futurs processeurs Intel auront un bit de sécurité nommé SMEP. Cette fonction « Supervisor Mode Execution Protection » (évoquée dans ce journal LinuxFr) va générer une erreur quand le noyau essaiera d’exécuter du code depuis une page marquée avec le bit user."
      
      se rapproche fortement du concept de ring
      
      "protection rings, are a mechanism to protect data and functionality from faults (fault tolerance) and malicious behaviour (computer security). "
      
      Pour info, cela était opérationnel dans les années 1965/1970 sur le couple Multics + GE645
      D'ou mon couplet de vieux snock (c'était mieux avant et patati et patata ...)
      
      D'aprés l'article sur les rings, les X86 en auraient 4, non utilisés par les OS actuels. A creuser
      
      Quant aux débordements d'entiers tout bon processeur se doit d'avoir un bit d'overflow sur les opérations entiéres, c'est le cas des X86.
      Donc charge aux développeurs de s'en servir (ou d'avoir les moyens de ...)
      Il en sera de même du futur bit SMEP
      
      Pour les débordements de buffer il me semble que c'est de la pure responsabilité du software
      sauf à créer des tampons pur-silicium autogérés ... encore une décennie ou deux soit patient ;-) !
      
      Pour finir un petit pour participer à l'éducation de nos jeunes lecteurs
      http://www.multicians.org/
      multics -> unix -> linux
      - [^] # Re: SMEP et la segmentation
        
        Posté par reno le 04 août 2011 à 09:33. Évalué à 4.
        
        OK, rien j'y suis allé trop fort: SMEP est une avancée intéressante.
        
        Quant aux débordements d'entiers tout bon processeur se doit d'avoir un bit d'overflow sur les opérations entiéres, c'est le cas des X86.
        
        Sauf qu'avec les MIPS, tu peux avoir des trap en cas de débordement sur les opérations entières et si tu as le bon gout de programmer en Ada, ça correspond à une exception, tout ça quasiment gratuitement au niveau performance, contrairement au test des bits d'overflow..
        
        sauf à créer des tampons pur-silicium autogérés ... encore une décennie ou deux soit patient ;-) !
        
        C'est à ça que je fais allusion avec les segments, mais vu la difficulté de faire évoluer les jeux d'instructions des CPUs, une ou deux décennies ne suffiront probablement pas..
        
        [^] # Re: SMEP et la segmentation
        
        Posté par dominique dechamps le 04 août 2011 à 16:44. Évalué à 1.
        
        Il semble que les X86 aient une instruction into qui permet de lever des exceptions sur bit d'overflow (voir http://www.gamedev.net/topic/310538-integer-overflow-exception/)
        
        Concernant les buffer overflow ce papier de 2002 http://www.acsac.org/2002/papers/classic-multics.pdf indique
        "However, when you look at the published history of Multics security problems
        [20, 28-30], you find essentially no buffer overflows.
        Multics generally did not suffer from buffer overflows, both because of the choice of implementation language and because of the use of several hardware features.
        These hardware and software features did not make buffer overflows impossible, but they did make such errors much less likely."
        et plus loin
        "In the case of the x86 processors, although the necessary segmentation features are
        present, they are almost never used, except for operating systems specifically designed for security, such as GEMSOS[32]."
        
        Donc j'ai franchement tendance à penser que tout est là pour "faire de la sécurité" et qu'il faut réinventer la roue (donc multics -> unix -> linux -> ? pour remplacer ce ? je propose linics mais je ne suis pas sûr cela plairait à Linus ... ça sonne trop minix)
        
        [^] # Re: SMEP et la segmentation
        
        Posté par reno le 04 août 2011 à 19:56. Évalué à 1.
        
        Il semble que les X86 aient une instruction INTO qui permet de lever des exceptions sur bit d'overflow
        
        Lever une exception de dépassement entier en une seule instruction c'est bien, mais ça fait quand un surcoût à l'exécution: les MIPS ont 2 variantes des instructions entières, une avec trap sur dépassement l'autre pas, donc il n'y a besoin d'ajouter aucune instruction supplémentaire..
        
        tout est là pour "faire de la sécurité"
        
        Tout était là pour faire de la sécurité: il n'y a plus de segments en mode 64bit sur les x86, comme les logiciels n'utilisaient pas la segmentation, AMD l'a retirer du jeux d'instruction pour le mode 64 bit :-(
        
        [^] # Re: SMEP et la segmentation
        
        Posté par Antoine le 04 août 2011 à 21:57. Évalué à 2.
        
        Tout était là pour faire de la sécurité: il n'y a plus de segments en mode 64bit sur les x86, comme les logiciels n'utilisaient pas la segmentation, AMD l'a retirer du jeux d'instruction pour le mode 64 bit :-(
        
        Je ne vois pas le rapport entre les segments et la sécurité. Le genre de protection que les segments apportent, c'est le système de pagination qui les apporte aujourd'hui, c'est tout.
        
        [^] # Re: SMEP et la segmentation
        
        Posté par reno le 05 août 2011 à 09:27. Évalué à 1.
        
        Tu l'as déjà marqué mais ce n'est pas parce que tu ne comprends pas que c'est vrai..
        Les protections ne sont pas les mêmes: les segments fournissent une protection à l'intérieur même d'un processus, c'est un peu comme si chaque tableau était dans son propre espace virtuel.
        Lis le lien de dominique dechamps sur multics, ça peut peut-être t'aider.
        
        [^] # Re: SMEP et la segmentation
        
        Posté par Antoine le 07 août 2011 à 14:34. Évalué à 2.
        
        Les protections ne sont pas les mêmes: les segments fournissent une protection à l'intérieur même d'un processus, c'est un peu comme si chaque tableau était dans son propre espace virtuel.
        
        Oui, bien sûr, sauf qu'il n'y a pas assez de registres de segments pour cela, il faut donc passer son temps à recharger un segment un ou l'autre, ce qui est certainement peu efficace.
        
        Enfin bon, si on veut absolument éviter les débordements de tableaux, on peut utiliser des structures de données adaptées au lieu d'imaginer des bidouilles architecturales. Ce n'est pas un hasard si ces problèmes ne se posent quasiment qu'en C.
        
        Lis le lien de dominique dechamps sur multics, ça peut peut-être t'aider.
        
        Je ne vois pas trop en quoi des choix faits sur un CPU des années 70 pourraient s'appliquer correctement aux architectures actuelles.
        
        [^] # Re: SMEP et la segmentation
        
        Posté par dominique dechamps le 08 août 2011 à 23:22. Évalué à 2.
        
        "Je ne vois pas trop en quoi des choix faits sur un CPU des années 70 pourraient s'appliquer correctement aux architectures actuelles."
        
        Mais des choix faits sur les CPU des années 70 sont dans les architectures actuelles. Rien n'est crée ex-nihilo et quoiqu'en dise la chanson, du passé on ne peut pas faire table rase.
        
        Pour preuve
        
        "Fenghua Yu submitted a series of patches to the upstream Linux kernel implementing support for a new Intel CPU feature: Supervisor Mode Execution Protection (SMEP). This feature is enabled by toggling a bit in the cr4 register, and the result is the CPU will generate a fault whenever ring0 attempts to execute code from a page marked with the user bit."
        voir blog de Dan Rosenberg
        
        a rapprocher de
        
        "Hardware supported rings were among the most revolutionary concepts introduced by the Multics operating system, a highly secure predecessor of today's UNIX family of operating systems." (voir article Wikipedia reference + haut)
        
        « Rien ne naît ni ne périt, mais des choses déjà existantes se combinent, puis se séparent de nouveau » Anaxagore de Clazomènes
        
        Trop fort Anaxagore! ;-)
        
        [^] # Re: SMEP et la segmentation
        
        Posté par Antoine le 15 août 2011 à 23:26. Évalué à 2.
        
        Mais des choix faits sur les CPU des années 70 sont dans les architectures actuelles.
        
        Lesquels ? Entre les caractéristiques d'implémentation d'un 8086 et celles d'un processeur Intel ou AMD d'aujourd'hui, il n'y presque rien en commun à part la compatibilité avec une variante obsolète du jeu d'instructions (puisque le mode réel, et même le mode 16 bits protégé ne sont plus utilisés).
        
        "Hardware supported rings were among the most revolutionary concepts introduced by the Multics operating system, a highly secure predecessor of today's UNIX family of operating systems."
        
        Dire que Multics était hautement sécurisé relève de la spéculation, car la sécurité informatique en tant que discipline n'existait pas à l'époque. Je rappelle que le premier ver Internet date de la fin des années 80.
        
        [^] # Re: SMEP et la segmentation
        
        Posté par reno le 09 août 2011 à 09:32. Évalué à 0.
        
        Oui, bien sûr, sauf qu'il n'y a pas assez de registres de segments pour cela,
        
        Soupir, là tu parles d'une implémentation spécifique, je ne vois pas de raison particulière pour laquelle les segments ne seraient pas efficace dans l'absolu
        (mais il y a un coût: stocker/relire le numéro de segment en mémoire n'est pas gratuit, mais vérifier le non-débordement des accès a un tableau est encore plus coûteux).
        
        Enfin bon, si on veut absolument éviter les débordements de tableaux, on peut utiliser des structures de données adaptées au lieu d'imaginer des bidouilles architecturales.
        
        Je ne vois pas de quoi tu parles, c'est quoi une structure de donnée adaptée qui remplace un tableau?
        Et puis qualifier un concept de bidouille parce que tu ne le connais pas, ça ne montre pas une grande ouverture d'esprit..
        
        Je ne vois pas trop en quoi des choix faits sur un CPU des années 70 pourraient s'appliquer correctement aux architectures actuelles.
        
        Directement non, mais c'est comme l'histoire, il faut connaître le passé pour pouvoir mettre en perspective les choix du présent: le x86 (beurk) n'est pas tout dans la vie..
        
        [^] # Re: SMEP et la segmentation
        
        Posté par Nicolas Boulay (site web personnel) le 12 août 2011 à 23:53. Évalué à 6.
        
        J'ai encore une fois l'impression que des softeux crois que le hardware est magique. Les sègments ne sont pas gratuit du tout, la pagination peut quasiment tout faire de la même façon. Intel avait un cpu qui gérait l'encapsulation des objets, le iAPX 432, sorti à 8 mhz, il était ridicule face au 386 à 20 mhz.
        
        "La première sécurité est la liberté"
        
        [^] # Re: SMEP et la segmentation
        
        Posté par ZeroHeure (site web personnel) le 14 août 2011 à 08:28. Évalué à 6.
        
        A lire tout ce fil, que je ne comprend pas vraiment (à mon avis j'y comprend rien), je me demande où vous avez apris tout ça (à part en école d'ingénieur)? Vous parlez de trap, segment, etc. je ne sais pas ce que c'est. C'est sans doute passionnant et puisque on parle d'Anaxagore, je vais citer Aristote:
        
        Tous les hommes ont par nature le désir de connaître.
        
        Alors connaissez-vous des sites où un demi-quart de softeu pourrait en apprendre un peu plus sur le fonctionnement d'un processeur? Tout en ne décollant pas trop des paquerettes. Une initiation quoi. Et aussi, est-ce qu'apprendre l'assembleur est la voie royale à toute cette connaissance?
        
        Bien humblement.
        
        "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
        
        [^] # Re: SMEP et la segmentation
        
        Posté par lasher le 15 août 2011 à 21:55. Évalué à 8.
        
        Alors, niveau articles électroniques, il y a les incontournables de Wikipedia: Segmentation_(informatique) et Pagination_(informatique). Si tu comprends l'Anglais, il ne faut pas oublier d'aller voir la version anglaise de ces pages (souvent plus complètes).
        
        Niveau bouquins papier, je connais quelques références :
        
        Andrew S. Tanenbaum : Modern Operating Systems (3rd Edition), qui existe en Français : Systèmes d'exploitation 3ème Ed.
        
        Andrew S. Tanenbaum : Structured Computer Organization (5th Edition), ou en Français : Architecture de l'ordinateur.
        
        Jean-Loup Baer : Microprocessor Architecture: From Simple Pipelines to Chip Multiprocessors (pas de traduction à ma connaissance)
        
        John Hennessy, David Patterson : Computer Organization and Design, Fourth Edition: The Hardware/Software Interface (je ne lui connais pas de traduction)
        
        John Hennessy, David Patterson : Computer Architecture, Fifth Edition: A Quantitative Approach, qui a une traduction en Français : Architecture des ordinateurs : une approche quantitative.
        
        Le bouquin sur les SE de Tanenbaum est très bien fait, décrit les différents problèmes qui se posent pour tout SE récent, et montre comment différents SE tentent de résoudre ces mêmes problèmes de différentes façon (Linux, Windows 2000). Il explique aussi quels mécanismes matériels sont indispensables à un SE moderne pour assurer certaines fonctionnalités (TLB pour l'interaction entre mémoire virtuelle, mémoire physique, caches; Test & Set ou Compare & Swap pour l'implémentation de verrous et de sections critiques en règle générale; etc.).
        
        Le bouquin de Tanenbaum sur l'archi des ordinateurs est supposé être très bon, mais je ne l'ai jamais lu.
        
        Le bouquin de Baer est une excellente introduction à l'architecture moderne des ordinateurs, avec un chapitre final qui explique comment sont architecturés des microprocesseurs avec plusieurs cœurs. Il décrit aussi comment fonctionne un microprocesseur avec instructions exécutées dans le désordre (« out-of-order engine »), comment les mémoires cache sont accédées, etc.
        
        Les deux bouquins de Hennessy & Patterson sont pour moi deux « bibles ». La première référence se situe « juste en dessous » du bouquin de Tanenbaum sur les OS. Le deuxième aborde des mécanismes relativement avancés utilisés dans les µ-proc actuels. Les exercices se chargent de faire « construire » un µ-proc RISC simplifié au lecteur.
        
        [^] # Re: SMEP et la segmentation
        
        Posté par Nicolas Boulay (site web personnel) le 16 août 2011 à 10:20. Évalué à 6.
        
        Je rajouterais qu'une bonne source de documentation est la doc produit par les constructeurs de cpu. Les guides de programmation sont en général plus facile d'accès que les guides de programmation système ou de description de l'architecture.
        
        "La première sécurité est la liberté"
        
        [^] # Re: SMEP et la segmentation
        
        Posté par lasher le 16 août 2011 à 16:18. Évalué à 2.
        
        Ah oui, j'oubliais, concernant les x86 (Intel et AMD) il y a www.agner.org.
        
        [^] # Re: SMEP et la segmentation
        
        Posté par reno le 16 août 2011 à 09:48. Évalué à 1.
        
        J'ai encore une fois l'impression que des softeux crois que le hardware est magique.
        
        Assertion gratuite..
        
        Les sègments ne sont pas gratuit du tout, la pagination peut quasiment tout faire de la même façon.
        
        Je suis plutôt d'accord, si un processus pouvait avoir plusieurs espaces d'adresses virtuelle interne, on pourrait avoir une protection matérielle des tableaux sans la complexité des segments.
        
        Intel avait un cpu qui gérait l'encapsulation des objets, le iAPX 432, sorti à 8 mhz, il était ridicule face au 386 à 20 mhz.
        
        Tu as dut louper le fait que le 386 a la segmentation dans ton argumentaire il me semble..
        La page de wikipedia parle d'un autre CPU qui avait des fonctionnalités similaire au iAPX 432 et était rapide, il est difficile de dire qu'une fonctionnalité a un coût particulier, ça dépend du niveau de la technologie, des interactions avec les autres fonctionnalités, des équipes..
        
        [^] # Re: SMEP et la segmentation
        
        Posté par Nicolas Boulay (site web personnel) le 16 août 2011 à 10:27. Évalué à 4.
        
        Le 386 ne gère que 4 segments. En général, dés qu'une ressource hardware est nécessaire en nombre, si on ne peut pas masquer le nombre réduit, on ne finit par ne plus l'utiliser. Il y a eu des sémaphores hardware, en plus de la pagination ou des ring d’exécution.
        _
        Je suis plutôt d'accord, si un processus pouvait avoir plusieurs espaces d'adresses virtuelle interne, on pourrait avoir une protection matérielle des tableaux sans la complexité des segments._
        
        Non, on ne pourrait pas. Le nombre de tableau serait toujours potentiellement plus grand que le nombre d'espace d'adressage que pourrait gérer un cpu. De plus, le changement d'espace d'adressage aurai un coup à l’exécution non négligeable.
        
        Si ton but est de protégé l'index d'un tableau, cela serait beaucoup plus facile d'avoir une instruction de test entre l'index et la taille maximum, avant un accès mémoire qui génère un trap en cas de débordement.
        
        "La première sécurité est la liberté"
        
        [^] # Re: SMEP et la segmentation
        
        Posté par Antoine le 19 août 2011 à 18:22. Évalué à 3.
        
        Je suis plutôt d'accord, si un processus pouvait avoir plusieurs espaces d'adresses virtuelle interne, on pourrait avoir une protection matérielle des tableaux sans la complexité des segments.
        
        Et le tout avec un nombre arbitraire de zones indépendantes définies à l'octet près, j'imagine ? Pourquoi penses-tu que l'implémentation serait plus simple que celle des segments ?
        
        [^] # Re: SMEP et la segmentation
        
        Posté par Antoine le 15 août 2011 à 23:37. Évalué à 3.
        
        Je ne vois pas de quoi tu parles, c'est quoi une structure de donnée adaptée qui remplace un tableau?
        
        Un tableau qui a connaissance de sa propre longueur, et qui fournit des abstractions interdisant les accès hors limites. Bref, ce qui se fait dans n'importe langage autre que le C, et explique que les débordements de limites dans ces autres langages n'existent pratiquement pas.
        
        il faut connaître le passé pour pouvoir mettre en perspective les choix du présent: le x86 (beurk) n'est pas tout dans la vie
        
        En attendant, le x86 est beaucoup plus exposé aux problématiques de sécurité que n'importe quel CPU ayant fait tourner Multics. C'est facile d'être « sécurisé » quand personne ne cherche à compromettre le système.
# process de développement

Posté par François Perrad (site web personnel) le 22 juillet 2011 à 12:20. Évalué à 10.

Le processus de développement (avec Git) est impressionnant par sa régularité depuis 6 ans.

Mais, comme un dessin vaut mieux qu'un long discours, voir http://fperrad.github.com/graph-versions/linux.html.
# magnifique journal

Posté par Stibb le 22 juillet 2011 à 12:23. Évalué à -1.

complete, instructif, intéressant, riche. Superbe article !
# dépêche linux3 par patrick_g en livret vacance (ed. DLFP)

Posté par Thomas Debesse (site web personnel) le 22 juillet 2011 à 17:37. Évalué à 10.

Merci encore pour cette dépêche !

Comme je n'aurais pas le temps de lire cela aujourd'hui et que je pars demain en vacances (7h de train) et que je n'ai pas vraiment prévu de me connecter… j'ai fait une chose que je n'avais jamais faite : imprimer une dépêche linuxfr !

Et comme y a du contenu à lire… je l'ai imprimé en livret. Il manquerait presque le sudoku et le test de personalité et je pourrais le refiler à ma voisine de train quand j'aurai fini ma lecture. :)

Malheureusement il va me manquer une chose essentielle, qui souvent complète et parfois dépasse la dépêche… les commentaires ! :'(

ce commentaire est sous licence cc by 4 et précédentes
- [^] # Re: dépêche linux3 par patrick_g en livret vacance (ed. DLFP)
  
  Posté par Thomas Debesse (site web personnel) le 22 juillet 2011 à 17:40. Évalué à 3.
  
  je corrige mon ingratitude :
  
  s/qui souvent complète et parfois dépasse la dépêche/qui toujours complète et souvent dépasse la dépêche/
  
  ce commentaire est sous licence cc by 4 et précédentes
- [^] # Re: dépêche linux3 par patrick_g en livret vacance (ed. DLFP)
  
  Posté par patrick_g (site web personnel) le 22 juillet 2011 à 19:10. Évalué à 10.
  
  Malheureusement il va me manquer une chose essentielle
  
  Il va surtout te manquer les hyperliens disséminés avec prodigalité dans la dépêche. J'essaye d'en mettre autant que je peux, car cela permet aux gens intéressés par un sujet d'approfondir un peu leur lecture.
  - [^] # Re: dépêche linux3 par patrick_g en livret vacance (ed. DLFP)
    
    Posté par Thomas Debesse (site web personnel) le 22 juillet 2011 à 21:42. Évalué à 4.
    
    Oui !
    j'aurai du changer le style avant impression pour ne pas donner de distinctions aux liens, et éviter de provoquer la frustration qui va m'être bien réelle : J'y peut pas clicker sur ce papier !
    
    ce commentaire est sous licence cc by 4 et précédentes
- [^] # Re:dépêchelinux3 par patrick_g en livret vacance (ed. DLFP)
  
  Posté par Juke (site web personnel) le 22 juillet 2011 à 19:34. Évalué à 10.
  
  Et comme y a du contenu à lire… je l'ai imprimé en livret.
  
  si tu as un livre electronique tu exporter l'article via weboob :
  
  boobmsg export_thread https://linuxfr.org/news/28329 -f xhtml -O kernel.xhtml
  
  puis le convertir avec calibre :
  
  book-convert kernel.xhtml kernel.epub
  
  bonnes vacances
# Qui peut m'expliquer?

Posté par GG (site web personnel) le 22 juillet 2011 à 19:46. Évalué à 1.
Bonjour,
je cite une partie de cette excellent dépêche:
Optimisations de perf

Le développeur Lin Ming, qui travaille chez Intel, a introduit une optimisation dans le code de l’outil de profilage perf. [...] l’ajout de ce fastpath en valait la peine. Les résultats sont assez impressionnants, puisque Lin Ming a annoncé les chiffres suivants pour la fonction find_probes() dans son message de commit :
```
* avant application du patch : 848 490 844 cycles pour 0,355 secondes ;
* après application du patch : 205 684 469 cycles pour 0,086 secondes.
```
en quoi les résultats sont "impressionnants"?
Pour moi, c'est du pareil au même, ou alors il y a une coquille dans les chiffres indiqués.

Bon vendredi
G

Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
- [^] # Re: Qui peut m'expliquer?
  
  Posté par patrick_g (site web personnel) le 22 juillet 2011 à 20:14. Évalué à 10.
  
  Avant le patch ton processeur est obligé de dépenser 850 millions de cycles alors qu'après l'application du patch il fait le même travail en seulement 200 millions de cycles.
  Ce n'est pas impressionnant pour toi ?
  
  Là ou j'aurais pu être plus clair c'est en remplaçant le "pour" par un "soit":
  
  848 490 844 cycles soit 0,355 secondes
  205 684 469 cycles soit 0,086 secondes
  - [^] # Re: Qui peut m'expliquer?
    
    Posté par BAud (site web personnel) le 23 juillet 2011 à 00:35. Évalué à -9.
    
    205 684 469 cycles soit 0,086 secondes
    
    mais euh concrètement c'est pour faire quoi ?
    si, c'est pour me branler la nouille, ça peut bien durer 10 min,je m'y reprendrai à deux fois, pour le plaisir.
    - [^] # Re: Qui peut m'expliquer?
      
      Posté par patrick_g (site web personnel) le 23 juillet 2011 à 07:21. Évalué à 10. Dernière modification le 23 juillet 2011 à 07:22.
      
      C'est pour insérer des sondes dans le noyau afin que perf puisse analyser ce qui se passe.
      Le message de commit indique la commande qui a été utilisée par Lin Ming pour tester :
      
      ./perf stat -e cycles -r 10 -- ./perf probe -k /home/mlin/vmlinux-s /home/mlin/linux-2.6 --vars csum_partial_copy_to_user > tmp.log
      
      Rien à voir avec ta nouille donc ;-)
# Ménage d'été

Posté par antistress (site web personnel) le 23 juillet 2011 à 04:38. Évalué à 2.

Merci pour cette dépêche désormais classique sur linuxfr

RC-3 : le lien wikipédia pour DRI n'est pas bon, c'est : http://fr.wikipedia.org/wiki/Direct_Rendering_Infrastructure je pense

Au final, ceux qui militaient pour que la v3.0 du noyau soit l'occasion de faire un grand ménage n'ont pas été entendus ?
- [^] # Re: Ménage d'été
  
  Posté par patrick_g (site web personnel) le 23 juillet 2011 à 07:17. Évalué à 5.
  
  Le lien est corrigé.
  Non, pas de grand ménage. Alan Cox avait milité pour qu'on vire tout le code de support des vieilles normes (ISA, MCA, EISA) mais Linus a refusé. Pour lui le changement de numérotation est juste cosmétique et il n'est pas question de bazarder des trucs qui marchent.
  - [^] # Re: Ménage d'été
    
    Posté par Tonton Benoit le 23 juillet 2011 à 12:25. Évalué à 8.
    
    Et le bus ISA est encore utilisé par certains capteurs sur les CM, on peut donc pas virer le support !
  - [^] # Re: Ménage d'été
    
    Posté par antistress (site web personnel) le 23 juillet 2011 à 14:28. Évalué à 1.
    
    merci :-)
# RC

Posté par Prae le 23 juillet 2011 à 08:38. Évalué à 3.

Y'a un truc que j'ai pas véritablement compris, c'est celui du nommage par RC.
J'ai probablement mal compris, mais quand tu dis "rc-1", "rc-2"; c'est à partir de Linux 3.0 ? c'est parce que avant ils utilisaient un autre système de numérotation ? (genre chiffre impaire pour les versions dev). Ou alors les RC ont toujours existé et c'est moi qui fume du GNU d'Amsterdam ?
- [^] # Re: RC
  
  Posté par patrick_g (site web personnel) le 23 juillet 2011 à 11:49. Évalué à 6.
  
  Les RC ce sont les "versions candidates". Au moment de la RC-1 Linus annonce que toutes les nouveautés du futur Linux 3.0 ont été intégrées et il sort une première version candidate: Linux 3.0-RC-1.
  Ensuite, au fil des semaines, on a des versions candidates successives jusqu'au moment ou Linus juge que la stabilité est satisfaisante et ou il sort la version définitive du noyau 3.0.
  - [^] # Re: RC
    
    Posté par gaaaaaAab le 23 juillet 2011 à 14:02. Évalué à 4.
    
    'R' comment 'veRsion' bien sûr ;-)
    
    En traduisant RC en version candidate, la notion de Release est carrément évacuée. En français, "Release Candidate (version)" serait plutôt "version candidate à la libération". Simple petit pinaillage sur les mots, sur le fond, ton explication est juste.
    
    Pour répondre au commentaire grand père, le concept (et le nom) de RC ne sont pas spécifiques à Linux, mais utilisés par pleins de logiciels. En règle générale, leur diffusion est restreinte, vu que ce sont des versions non finales. Hors la visibilité du noyau (et les dépèches de patrick_g !), ça resterait du jargon de gens du métier.
    
    sinon, excellente dépêche comme d'habitude. Les micro interviews sont vraiment une bonne idée.
    
    Juste un petit regret, https://lwn.net/Articles/452117/ n'est pas en accès libre.
    - [^] # Re: RC
      
      Posté par patrick_g (site web personnel) le 23 juillet 2011 à 14:34. Évalué à 4.
      
      Juste un petit regret, https://lwn.net/Articles/452117/ n'est pas en accès libre.
      
      Ce sera en accès libre dès jeudi prochain.
      - [^] # Re: RC
        
        Posté par gaaaaaAab le 23 juillet 2011 à 15:28. Évalué à 2.
        
        ok merci, pas de regrets alors :)
    - [^] # Re: RC
      
      Posté par Prae le 25 juillet 2011 à 05:35. Évalué à 2.
      
      Pour répondre au commentaire grand père, le concept (et le nom) de RC ne sont pas spécifiques à Linux, mais utilisés par pleins de logiciels.
      
      Alors merci d'avoir pris le temps de répondre à ceci. Mais (oui parce qu'il y a un mais), c'est pas comme-ci je bossais dans l'univers du LL depuis mi-90, donc les RC je connais quand même "un tout petit peu". Ma question portait sur le fait que l'article ainsi écrite, le paragraphe sur les RC laissait supposer que Linus avait décidé d'un changement de nom de versioning pour les Linux >= 3.0
      - [^] # Re: RC
        
        Posté par gaaaaaAab le 26 juillet 2011 à 08:29. Évalué à 4.
        
        ah désolé, j'avais mal compris ton commentaire initial. A ma décharger, à lire la réponse de patrick_g, j'ai l'impression que je suis pas seul dans ce cas là :)
  - [^] # Re: RC
    
    Posté par Prae le 25 juillet 2011 à 05:31. Évalué à 0.
    
    Alors c'est bizarre dans ton article, ca laisse supposer qu'il y a eu changement de nom pour les versioning. C'est bizarre que tu en parles si rien ne change alors
    
    (merci aux personnes m'ayant moinssé, à priori, y'avait rab' de mousses aux chocolats ce midi)
# Makefile

Posté par Prae le 23 juillet 2011 à 09:42. Évalué à 10.

Question annexe: je vois que pas mal de gens râlent sur Makefile (Linus en premier). N'y a t'il eu jamais de discussion à propos d'un remplaçant ?
- [^] # Re: Makefile
  
  Posté par imr le 23 juillet 2011 à 16:38. Évalué à 10.
  
  Envoie un mail à Lennart Poettering, il va arranger ça.
- [^] # Re: Makefile
  
  Posté par Jux (site web personnel) le 24 juillet 2011 à 06:56. Évalué à 8.
  
  Quand Linus s'énerver, il en sort quelque chose de bien (git). Reste à espérer qu'il s'énervera suffisamment sur make pour écrire un remplaçant :)
  - [^] # Re: Makefile
    
    Posté par zebra3 le 24 juillet 2011 à 22:04. Évalué à 10.
    
    Quand Linus fâché, lui toujours faire ainsi.
    
    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
- [^] # Re: Makefile
  
  Posté par Sphax le 25 juillet 2011 à 10:28. Évalué à 0.
  
  J'ai beau chercher, je ne vois pas où Linus (ni quelqu'un d'autre) parle de make, mais peut-être que je cherche mal. Tu aurais un lien ?
  - [^] # Re: Makefile
    
    Posté par patrick_g (site web personnel) le 25 juillet 2011 à 10:44. Évalué à 3.
    
    C'est dans la partie sur le prefetch : https://linuxfr.org/news/le-noyau-linux-est-disponible-en-version%C2%A030#toc_13
    
    Si tu veux aller plus loin que ma traduction, alors le mail d'origine de Linus est ici : http://thread.gmane.org/gmane.linux.kernel.cross-arch/9810
    - [^] # Re: Makefile
      
      Posté par Sphax le 25 juillet 2011 à 11:06. Évalué à 1.
      
      Merci, j'aurai du chercher avec "make" plutôt que "makefile".
    - [^] # Re: Makefile
      
      Posté par Mathieu Segaud le 08 août 2011 à 13:19. Évalué à 2.
      
      euh, dans ce mail non plus, je ne vois pas où il dit qu'il veut changer "make". Il dit juste, et c'est ni la première ni la dernière fois, que les mécanismes de prefetching sont pourris, et trop génériques, et qu'on finit tjs pas trouver des benchmarks, qui te montreront que c'est nuisible dans 50% des cas, et utile dans les 50%. A priori, ce qu'il peut reprocher au build system, c'est pas que c'est "make" qui est nul, mais que le system permet d'exhiber un cas complètement contre-performant de prefetching quand selinux est activé, dans le cas d'un compilation lancée après qq changements seulement dans l'arbre des sources (qui prend du coup des plombes).
# Btrfs

Posté par Donk le 23 juillet 2011 à 12:09. Évalué à 5.

Est-ce que, à terme, si on utilise btrfs pourra-t-on se passer de lvm2 et de mdadm?
- [^] # Re: Btrfs
  
  Posté par GeneralZod le 23 juillet 2011 à 16:22. Évalué à 8.
  
  Pour la plupart des usages, oui. Dans le cas du RAID, btrfs ne supporte que les modes 0/1/10, Chris Mason bosse sur les modes 5/6 mais c'est en basse priorité. Si Btrfs arrive au même niveau de fonctionnalité que ZFS, à priori, plus besoin de LVM.
  - [^] # Re: Btrfs
    
    Posté par gouttegd (site web personnel) le 24 juillet 2011 à 11:28. Évalué à 10.
    
    Je ne suis pas sûr que ça me plaise, ça…
    
    Je trouve bien pratique que les fonctionnalités de type RAID et la gestion des « volumes logiques » soient indépendantes du système de fichier. Je ne vois pas trop ce qu’on gagne à intégrer ça dans le système de fichier lui-même.
    
    Par exemple, sur une de mes machines j’ai la configuration suivante : deux disques formant un volume RAID 1, lui-même chiffré par dm-crypt, le volume chiffré servant à son tour de volume physique LVM2 contenant tous les volumes logiques dont j’ai besoin (/, /home, swap, etc.). Si Btrfs remplace à la fois la couche RAID et la couche LVM2, comment intercaler la couche de chiffrement entre les deux ? Si on chiffre en-dessous de Btrfs, alors pour un miroir à deux disques on se retrouve à chiffrer deux fois chaque donnée. Si on chiffre au-dessus de Btrfs, alors il faudra un volume dm-crypt par « volume logique ».
    
    Et quid de la partition de swap ? Dans mon installation actuelle, elle est redondée et chiffrée comme tous les autres volumes logiques. Comment fait-on ça si la redondance est implémentée au niveau du système de fichier et non dans une couche indépendante ?
    
    A priori (mais j’admet ne pas m’être encore renseigné en détail sur Btrfs), il me semble qu’on perd en souplesse par rapport au modèle actuel.
    - [^] # Re: Btrfs
      
      Posté par Kerro le 24 juillet 2011 à 12:43. Évalué à 9.
      
      Je suis du même avis que toi. Chaque outil est une brique qu'on peut empiler comme on le souhaite (y compris de manière débile, c'est le problème de l'admin, pas du développeur).
      
      Cela dit, rien n'oblige à utiliser le RAID de brtfs, donc ton schéma actuel est toujours exploitable.
      D'autant plus que le RAID de type 'md' a des possibilités sympathiques. Par exemple un des miroirs peut être en écriture seule sur une machine distante. Il y a aussi la notion de bitmap, très utile dans ce cas précis.
      
      Peut-être que le RAID intégré à brtfs apporte un gain de performances ?
      Je ne connais pas le sujet, mais à première vue, j'en doute.
    - [^] # Re: Btrfs
      
      Posté par ymorin le 24 juillet 2011 à 12:46. Évalué à 10.
      Je ne suis pas sûr que ça me plaise, ça…
      
      Entièrement d'accord la dessus.
      
      Ceci dit, ext{2,3,4}fs ont eux aussi un support du RAID. Lors de la création du FS ext, on peut spécifier certains paramètres qui permettent d'optimiser le FS en fonction du RAID sous-jacent ; ce sont les options étendues (extended options dans la page de man) suivantes :
      
      stride : c'est le nombre de blocks contigus sur un disque
      
      stripe-width : c'est le nombre de blocks contigus sur les disques de données
      
      D'un autre côté, si on peut juste utiliser btrfs au-dessus d'un RAID, alors on peut aussi s'en ficher que btrfs gère nativement du RAID.
      
      Donc, reste à savoir ce que supporter le RAID veut dire. Pour extfs, c'est une optimisation du placement des méta données. Pour btrfs, je ne sais pas.
      
      Hop,
      Moi.
    - [^] # Re: Btrfs
      
      Posté par Antoine le 24 juillet 2011 à 15:42. Évalué à 10.
      
      Je trouve bien pratique que les fonctionnalités de type RAID et la gestion des « volumes logiques » soient indépendantes du système de fichier. Je ne vois pas trop ce qu’on gagne à intégrer ça dans le système de fichier lui-même.
      
      Je suis d'accord, il vaudrait mieux implémenter tout ça dans systemd.
    - [^] # Re: Btrfs
      
      Posté par GeneralZod le 26 juillet 2011 à 03:59. Évalué à 9.
      btrfs ne t'empêche pas d'utiliser le RAID logiciel et/ou LVM2. Par ailleurs, quitte à faire du RAID, autant que ce soit du RAID matériel, quand à LVM2, c'est une rustine qui apporte un poil de souplesse mais aussi son lot d'emmerdes.
      
      personnellement, j'estime que ce sont des fonctionnalités qui ont vocation à être intégré dans le système de fichiers, pour diverses raisons:
      
      simplicité d'administration
      
      fiabilité et performance: multiplier les couches au niveau de la gestion des disques n'a jamais amélioré ces deux points, bien au contraire.
      
      interopérabilité: chaque OS développe sa couche de gestion de volumes logiques et se débrouille pour qu'elles soient toutes incompatibles entre elles. btrfs réponds à 95% des besoins des utilisateurs plus ou moins avancés en étant plus fiable, plus performant et plus simple, pour les 5% restant, LVM2 et mdam sont toujours là.
      
      PS: le RAID intégré à Btrfs est un poil plus performant principalement à cause du Copy-On-Write, en se donnant le luxe d'être plus fiable si on fait du mirroring. Supposons que j'ai deux disques dont l'un est malade, avec le mirroring classique, aucun moyen de deviner si mes données sont bonnes ou pas, Btrfs est capable de vérifier si les données et le checksum enregistré correspondent et te renvoyer la bonne donnée.
      - [^] # Re: Btrfs
        
        Posté par gouttegd (site web personnel) le 26 juillet 2011 à 20:46. Évalué à 10.
        
        btrfs ne t'empêche pas d'utiliser le RAID logiciel et/ou LVM2.
        
        Bien sûr, et je compte bien là-dessus.
        
        Par ailleurs, quitte à faire du RAID, autant que ce soit du RAID matériel
        
        Bof, je n’ai jamais été convaincu par le RAID matériel.
        
        Les contrôleurs RAID matériels ne sont pas forcément compatibles entre eux, un disque membre d’une matrice gérée par un contrôleur A peut ne pas être utilisable avec un contrôleur B ; le jour où il faut remplacer le contrôleur A, ou le jour où je veux transférer les disques sur une autre machine équipée du contrôleur B, je fais quoi ? Le RAID logiciel apporte une appréciable indépendance vis-à-vis du matériel, au prix certes d’une dépendance au système mais pour moi c’est un moindre mal — je ne sais pas si j’aurais dans cinq ans le même matériel qu’aujourd’hui, mais je sais que j’utiliserai encore GNU/Linux.
        
        personnellement, j'estime que ce sont des fonctionnalités qui ont vocation à être intégré dans le système de fichiers, pour diverses raisons:
        
        Faudrait savoir, je croyais que ça devait se situer au niveau du matériel ?
        
        interopérabilité: chaque OS développe sa couche de gestion de volumes logiques et se débrouille pour qu'elles soient toutes incompatibles entre elles.
        
        Et en quoi intégrer ces fonctionnalités dans un nouveau système de fichiers dans notre coin change cette situation ? Btrfs est compatible avec les autres systèmes de fichiers qui adoptent la même approche dans leur coin, comme ZFS ?
        
        btrfs réponds à 95% des besoins des utilisateurs plus ou moins avancés en étant plus fiable, plus performant et plus simple, pour les 5% restant, LVM2 et mdam sont toujours là.
        
        Je dois donc faire partie des 5 % des utilisateurs plus avancés qui ne peuvent être satisfaits par Btrfs. C’est bizarre, je n’avais pas réalisé à quel point mes besoins sortaient de l’ordinaire.
        
        [^] # Re: Btrfs
        
        Posté par Fabien (site web personnel) le 26 juillet 2011 à 21:14. Évalué à 1.
        
        Faut dire qu'il y a les "bons" contrôleurs RAID matériel et les "mauvais" contrôleurs RAID matériel, les bons sont ceux qui ... (je m'égare)
        
        Ton argument pour le 'contre' est pertinent mais d'un autre coté, les "bons" contrôleurs RAID matériel apportent certains avantages qui ne pourront jamais être proposés par le software, je pense à la batterie intégrée au contrôleur par exemple.
        
        [^] # Re: Btrfs
        
        Posté par gouttegd (site web personnel) le 26 juillet 2011 à 21:42. Évalué à 3.
        
        Faut dire qu'il y a les "bons" contrôleurs RAID matériel et les "mauvais" contrôleurs RAID matériel, les bons sont ceux qui ... (je m'égare)
        
        Le mauvais contrôleur RAID, il voit une donnée, bam il la recopie, alors que le bon contrôleur, il voit une donnée… bon ben il la recopie, mais c’est un bon contrôleur.
        
        Blague à part, quand je me suis renseigné sur la question j’ai trouvé que les constructeurs étaient assez avares en informations. Comment sait-on quels sont les contrôleurs compatibles entre eux ? Le seul conseil que j’ai trouvé est de prendre des contrôleurs du même constructeur et « d’à peu près le même modèle »… Je ne trouve pas ça très engageant. Si j’achète un contrôleur RAID aujourd’hui, que demain le constructeur arrête de produire ce modèle et qu’après-demain il tombe en panne (apparemment, ça arrive), je fais quoi ?
        
        Je pense que je préfère faire confiance aux développeurs de la couche RAID du noyau Linux (ou de la couche équivalente sur les autres systèmes).
        
        je pense à la batterie intégrée au contrôleur par exemple.
        
        Euh, elle peut servir à quoi ? (C’est une vraie question.)
        
        [^] # Re: Btrfs
        
        Posté par ymorin le 26 juillet 2011 à 21:58. Évalué à 4.
        
        je pense à la batterie intégrée au contrôleur par exemple.
        
        Euh, elle peut servir à quoi ? (C’est une vraie question.)
        
        Les contrôleurs RAID matériels ont une grosse quantité de RAM qui sert de cache :
        
        optimiser la lecture en gardant les blocs les plus lus
        
        optimiser les écritures en ré-ordonnant les accès
        
        Dans le cas de l'écriture différée, l'OS croit avoir écrit sur le disque, alors que le contrôleur le garde en mémoire. La batterie va permettre au contrôleur RAID de terminer l'écriture des blocs en l'air et ainsi garantir l'intégrité des données : ce que l'OS croit avoir écrit, bin en fait, c'est réellement écrit !
        
        Dans des cas extrêmes, ca permet même de garantir le maintien du cache de lecture pour avoir un boot plus rapide. Mais là, on atteint des sommets... en coût du contrôleur, pour un gain discutable...
        
        Hop,
        Moi.
        
        [^] # Re: Btrfs
        
        Posté par __o le 31 juillet 2011 à 17:47. Évalué à 1.
        
        Intuitivement, ça a un intérêt très limité:
        
        Quand on fait des écritures à une vitesse plus rapide que les disques ne peuvent écrire (ce qui est toujours le cas, sinon on a pas besoin de cache), le cache se rempli très vite (vu qu'il y a plus de données qui entrent dans le cache que de données qui en sortent).
        
        Donc le cache est toujours saturé. Et lorsque le cache est saturé, pour écrire dans le cache il faut d'abord qu'une partie des données en cache soient réellement écrites sur le disque.
        
        Et donc au bout de quelques secondes ou minutes d'utilisation, on obtient les mêmes performances qu'un contrôleur sans cache, non ?
        
        optimiser la lecture en gardant les blocs les plus lus
        
        il me semble que linux fait ça très bien déjà, et vu qu'il n'y a pas besoin que ce cache survive à un arrêt du système, on peut très bien laisser linux s'en occuper. D'autant plus que ça doit certainement être moins coûteux pour le système de lire une page de cache en mémoire que de demander une page au contrôleur.
        
        [^] # Re: Btrfs
        
        Posté par Antoine le 01 août 2011 à 17:24. Évalué à 6.
        
        Donc le cache est toujours saturé. Et lorsque le cache est saturé, pour écrire dans le cache il faut d'abord qu'une partie des données en cache soient réellement écrites sur le disque.
        
        Et donc au bout de quelques secondes ou minutes d'utilisation, on obtient les mêmes performances qu'un contrôleur sans cache, non ?
        
        Si tu as un débit d'écriture constant au fil du temps, oui. Enfin, il me semble que la plupart des machines ne sont pas utilisées sur ce principe. Il y a typiquement des périodes sans aucune charge et des pics de charge temporaire. Il y a aussi le fait que sur beaucoup de services (du genre HTTP), les temps de réponse sont importants pour assurer une bonne qualité, donc il faut éviter que des écritures sur le système de fichier puissent bloquer pendant une seconde si d'autres requêtes sont en cours simultanément.
        
        [^] # Re: Btrfs
        
        Posté par __o le 02 août 2011 à 18:04. Évalué à -2.
        
        Donc ce cache ne sert qu'à lisser des piques d'I/O sur des machines peu utilisées ?
        
        Si tu as un débit d'écriture constant au fil du temps enfin, il me semble que la plupart des machines ne sont pas utilisées sur ce principe.
        
        Un serveur web (ou le serveur de base de données qui est derrière) qui fait plein de petites requêtes par seconde a un débit d'I/O à peu près constant.
        
        Et sur ces machines, un cache d'écriture se remplis tellement rapidement que ça ne sert à rien.
        
        [...] temps de réponse sont importants [...] des écritures puissent bloquer pendant une seconde
        
        Sur un service où les temps de réponse sont importants, on écrit pas du code qui arrive à faire tellement d'I/O d'un coup qu'il bloque toutes les autres requêtes pendant une seconde, sur un serveur qui était pourtant sans aucune charge.
        
        [^] # Re: Btrfs
        
        Posté par wismerhill le 02 août 2011 à 23:23. Évalué à 3.
        
        Un serveur web (ou le serveur de base de données qui est derrière) qui fait plein de petites requêtes par seconde a un débit d'I/O à peu près constant.
        
        Non, sur une moyenne de quelques dizaines de secondes c'est à peu près constant, mais si tu le regarde au dizième de seconde près tu constatera que ça ne l'est pas.
        
        Et sur ces machines, un cache d'écriture se remplis tellement rapidement que ça ne sert à rien.
        
        Un serveur web fait beaucoup plus de lectures que d'écritures, et s'il doit relire une donnée qu'il vient d'écrire peu de temps avant il y a un gros gain si celle-ci est encore en cache.
        (mais là j'ai plus en tête la cache RAM gérée par Linux, je n'ai pas vraiment d'expérience avec de gros contrôleurs SCSI avec plein de Mo de cache intégrée)
        
        [^] # Re: Btrfs
        
        Posté par __o le 03 août 2011 à 10:20. Évalué à 1.
        
        sur une moyenne de quelques dizaines de secondes c'est à peu près constant, mais si tu le regarde au dizième de seconde près tu constatera que ça ne l'est pas.
        
        Évidemment. Tout ce qui compte c'est si cette moyenne est supérieure à ce que le support de stockage peut absorber. Si elle l'est, le cache d'écriture se rempli.
        
        Un serveur web fait beaucoup plus de lectures que d'écritures,
        
        Oui. Je parlais surtout du serveur de base de données qui est derrière en fait. C'est très courant un serveur de base de données dont les I/O sont le goulot d'étranglement.
        
        et s'il doit relire une donnée qu'il vient d'écrire peu de temps avant il y a un gros gain si celle-ci est encore en cache. (mais là j'ai plus en tête la cache RAM gérée par Linux
        
        Tout à fait, je disais exactement ça quelques messages plus haut, pour le cache de lecture.
        
        [^] # Re: Btrfs
        
        Posté par Antoine le 03 août 2011 à 04:33. Évalué à 1.
        
        Sur un service où les temps de réponse sont importants, on écrit pas du code qui arrive à faire tellement d'I/O d'un coup qu'il bloque toutes les autres requêtes pendant une seconde, sur un serveur qui était pourtant sans aucune charge
        
        On peut aussi se forcer à utiliser un Z80 pour prouver qu'on est capable d'écrire du code optimisé, mais en pratique, si ajouter une fraction de salaire en matériel permet de régler un problème de performance, je ne vois pas de raison de se priver. Il faut garder à l'esprit que bien souvent le matériel informatique coûte moins cher que l'optimisation d'un logiciel dédié.
        
        [^] # Re: Btrfs
        
        Posté par wismerhill le 03 août 2011 à 18:59. Évalué à 7.
        
        Il faut garder à l'esprit que bien souvent le matériel informatique coûte moins cher que l'optimisation d'un logiciel dédié.
        
        Quand le logiciel en question n'est utilisé que par une poignée de personnes, peut-être.
        S'il est utilisé par des milliers de personnes c'est beaucoup plus économique de passer quelques jours à bien optimiser le logiciel plutôt que de forcer des milliers de personnes à racheter du matériel (et peut-être jeter du matériel parfaitement fonctionnel).
        
        [^] # Re: Btrfs
        
        Posté par Fabien (site web personnel) le 26 juillet 2011 à 23:50. Évalué à 3.
        
        La batterie permet d'alimenter le contrôleur et les disques durs indépendamment de l'alimentation générale.
        En cas de de crash électrique, je suis certain que les données ayant été signifiées comme écrites sur disque le sont sont bien physiquement, même en cas de cache menteur sur les disques.
        Suivant le type de contrôleur, tu peux régler pas mal d'options depuis leur propre 'bios' (voir même directement depuis l'OS si les outils sont disponibles). Avec les contrôleurs PERC par exemple, je forçais le sync sur disque pour les bases de données car je ne pouvais pas me permettre de perdre une seule transaction.
        
        Dernièrement, j'ai repris l'admin d'un serveur chez ovh avec raid software et c'est pas du tout la joie quand mdadm vérifie/reconstruit périodiquement le raid1 de 1.5To. Bien que la comparaison soit biaisée avec mon expérience des contrôleurs matériels (car disques durs SAS 15ktr/min ...), je ne me souviens pas avoir enduré de telles lenteurs.
        
        [^] # Re: Btrfs
        
        Posté par Hobgoblins Master (Mastodon) le 27 juillet 2011 à 00:59. Évalué à 3.
        
        Tu devrais peut-être penser à ajouter un bitmap interne à ton raid, ça accélère bien certaines reconstructions…
        
        [^] # Re: Btrfs
        
        Posté par gouttegd (site web personnel) le 27 juillet 2011 à 02:33. Évalué à 2.
        
        En cas de de crash électrique, je suis certain que les données ayant été signifiées comme écrites sur disque le sont sont bien physiquement, même en cas de cache menteur sur les disques.
        
        Un problème qui n’existerait pas si le contrôleur disque se contentait de faire son boulot (écrire les requêtes dans l’ordre où l’ordonnanceur du système les lui envoie, et répondre qu’elles ont été écrites une fois que c’est réellement fait) au lieu de jouer au plus malin…
        
        Devoir rajouter un contrôleur RAID pour s’assurer que le contrôleur disque a bien fait son job, j’ai du mal à voir ça comme une bonne idée. Pourquoi pas un contrôleur de contrôleur RAID aussi, pour s’assurer que quand le contrôleur RAID prétend au système que le contrôleur disque prétend avoir écrit les données, elles ont bien été écrites ?
        
        [^] # Re: Btrfs
        
        Posté par Kerro le 28 juillet 2011 à 00:24. Évalué à 3.
        
        A savoir: certains (beaucoup ?) disque SCSI font croire que les données sont écrites alors que ce n'est pas le cas. A moins que ce ne soit le contrôleur (HP) ?
        
        J'ai eu l'exemple sur des Maxtor qui étaient capables de faire un nombre d'écritures tellement énorme dans un gros fichier que s'en était impossible. C'était du genre 1000 écritures non séquentielles par seconde (un disque 10.000 tours/minute ne fait que 166 tours par seconde. Il n'est que difficilement possible qu'il puisse écrire plus de 166 fois par seconde de manière non séquentielle).
        
        D'autres ont eu des choses du même genre ?
        
        [^] # Re: Btrfs
        
        Posté par Alex le 26 juillet 2011 à 21:26. Évalué à 3.
        
        Faudrait savoir, je croyais que ça devait se situer au niveau du matériel ?
        
        Il ne parlait que du raid, lvm, dm-* et brtfs ne font pas que du raid
        
        Btrfs est compatible avec les autres systèmes de fichiers qui adoptent la même approche dans leur coin, comme ZFS ?
        
        Je pense qu'il rêve que brtfs soit porté sur d'autres os. Si c'est ça je pense que c'est en effet qu'un rêve. Sous license BSD pourquoi pas, *BSD l'auraient peut être repris et peut être même apple (qui voulait porter zfs il n'y a pas si longtemps). On peut espérer que d'autres en fasse une nouvelle implémentation sans reprendre les sources sous gpl, mais j'y crois assez peu.
        
        [^] # Re: Btrfs
        
        Posté par GeneralZod le 27 juillet 2011 à 01:15. Évalué à 4.
        
        Je pense qu'il rêve que brtfs soit porté sur d'autres os. Si c'est ça je pense que c'est en effet qu'un rêve. Sous license BSD pourquoi pas, *BSD l'auraient peut être repris et peut être même apple (qui voulait porter zfs il n'y a pas si longtemps). On peut espérer que d'autres en fasse une nouvelle implémentation sans reprendre les sources sous gpl, mais j'y crois assez peu.
        
        ZFS est sous licence CDDL, ça n'a pas empêché FreeBSD de fournir le support de ZFS en réutilisant le code d'OpenSolaris (sous forme d'un module noyau), rien n'empêcherait les *BSD de fournir le support de Btrfs sous forme d'un module noyau (pour respecter le sacro-saint principe que le système de base est 100% BSD, hein, dans l'absolu, rien n'interdit de fournir un noyau BSD avec le support de Btrfs en statique).
        Au passage, la CDDL (qui n'est qu'une vilaine MPL maquillée par feu Sun) n'est pas plus BSD-friendly que la GPL.
        
        [^] # Re: Btrfs
        
        Posté par GeneralZod le 27 juillet 2011 à 01:05. Évalué à 5.
        
        Les contrôleurs RAID matériels ne sont pas forcément compatibles entre eux
        
        Pour le matériel grand public, c'est effectivement un problème, pour le matériel pro, c'est le problème de ton fournisseur. Néanmoins, t'as des perfs bien meilleures et une sûreté de fonctionnement nettement supérieure (cache non volatile, contrôle des erreurs etc ...)
        
        Faudrait savoir, je croyais que ça devait se situer au niveau du matériel ?
        
        Je veux bien voir du LVM au niveau matériel ... Un système de fichiers moderne se doit d'intégrer des fonctionnalités de RAID logiciel et de LVM (du moins le sous-ensemble de fonctionnalités le plus usité, pas forcément les plus sioux)
        
        Je dois donc faire partie des 5 % des utilisateurs plus avancés qui ne peuvent être satisfaits par Btrfs
        
        Pas satisfait des fonctionnalités RAID logiciel et LVM de Btrfs, derrière, tu gagnes un système de fichiers plus fiable à terme (COW, transactions etc...), plus performant (fsck), compression à la volée.
        
        C’est bizarre, je n’avais pas réalisé à quel point mes besoins sortaient de l’ordinaire.
        
        C'est pas une tare ...
        
        [^] # Re: Btrfs
        
        Posté par gouttegd (site web personnel) le 27 juillet 2011 à 02:46. Évalué à 3.
        
        Pour le matériel grand public, c'est effectivement un problème, pour le matériel pro, c'est le problème de ton fournisseur.
        
        Donc pour moi, c’est un problème, et largement suffisant pour discréditer les solutions matérielles à mes yeux, peu importe les merveilles que peuvent me faire miroiter leurs constructeurs. Les « pros » peuvent certainement se permettre de passer par un intermédiaire à qui ils pourront dire « c’est votre problème, débrouillez-vous je veux que ce soit résolu pour avant-hier matin », moi pas.
# Pile réseau : problème de droits d’auteur

Posté par swilmet le 25 juillet 2011 à 20:44. Évalué à 7.

Dans l'entretien avec Éric Dumazet :

[...] De manière générale, est‐ce que tu regardes les systèmes BSD pour les comparer avec Linux ?
[...] je ne regarde pas le code de FreeBSD : je préfère que les développements Linux soient « self contained », pour éviter des contaminations pouvant poser problème de droits d’auteur.

Je trouve ça dommage, pcq la pile réseau des systèmes BSD est réputée meilleure et plus performante (malheureusement je n'ai pas de lien, et peut-être que maintenant ce n'est plus le cas).

De plus, à moins que ça soit couvert par des brevets (ce qui m'étonnerait), s'inspirer d'un code sous licence BSD ne doit surement pas poser de problèmes de droits d'auteur.
- [^] # Re: Pile réseau : problème de droits d’auteur
  
  Posté par Kerro le 25 juillet 2011 à 22:45. Évalué à 6.
  
  la pile réseau des systèmes BSD est réputée meilleure et plus performante
  
  Ce n'est effectivement plus le cas. Peut-être depuis longtemps.
  Un énorme avantage de la pile réseau BSD est sa licence. En mettant ça dans de l'embarqué, perdre 1% en performance réseau n'est pas très importante. Et encore, il faudrait atteindre 1%.
  - [^] # Re: Pile réseau : problème de droits d’auteur
    
    Posté par Joris Dedieu (site web personnel) le 26 juillet 2011 à 23:35. Évalué à 4.
    
    Ce n'est effectivement plus le cas. Peut-être depuis longtemps.
    
    A bon ? Tu as des sources ? parce que ça m'intéresse fortement.
    
    Je ne sais pas si les piles réseau de FreeBSD et DragonFlyBSD sont plus performante que celle de Linux. Mais de mon expérience en tout cas, elles sont bien plus stables en haute charge. Et donc en ce sens meilleures.
    
    Après je suis avide de retours en ce domaine donc n'hésites pas. Pour l'heure en tout cas, si je peux me passer de Ciscos c'est uniquement grâce à FreeBSD et DragonFlyBSD (et un peu de réflexion sur la topologie tout de même).
    
    Pour OpenBSD / NetBSD je ne sais pas.
    - [^] # Re: Pile réseau : problème de droits d’auteur
      
      Posté par Kerro le 27 juillet 2011 à 01:28. Évalué à 7.
      
      Ton constat de différence vient peut-être des réglages par défaut des distributions. Les BSD sont peut-être mieux faits de ce côté là (pour le pare-feu, y'a pas photo). Mais lorsqu'on a des débit monstrueux, les réglages par défauts ne sont pas sensés être pertinents. C'est l'admin qui est sensé savoir sur quelle manette agir.
      Concernant Linux, il n'y a que peu à faire pour s'assurer que tout va bien se passer avec de gros débits. A supposer qu'on a le bon matériel, car pour saturer une machine milieu de gamme actuelle, il faut se lever tôt. Et pour saturer une grosse bécane, ça coûte les deux bras en cartes réseau.
      
      Il est possible que le fait que les BSD aient un moins bon rendement lorsque la puissance demandée augmente (scaling) y fait quelque chose. Les réglages sont plus conservateurs, moins d'allocation de mémoire etc. Pour traiter du réseau ça passe sans soucis.
      C'est une hypothèse.
      
      Je n'ai pas d'autres retours que mon expérience et celle des autres.
      Je ne connais personne qui m'ait montré en vrai un Linux planté à cause de la charge de sa pile réseau. Ni un BSD.
      Et les tests de hammering ne semblent pas indiquer qu'un Linux s'écroule sous la charge. Pas plus qu'un BSD.
      
      Par contre un Linux mal configuré par rapport à la charge encaissée, il y en a des caisses. Tu tapes une commande et elle s'exécute 20 minutes après tellement ça swape. Donc machine inutilisable. Et ça il y en a des tonnes en entreprise. Ce serait du BSD, je doute qu'on trouve une différence.
      Par exemple une machine qui doit réagir vite... mais on lui colle 4 Go de swap et pas de limites aux processus. Forcément un jour ou l'autre il y a un hic.
      Pareil avec les cartes réseau de la mort qui stockent des tonnes de paquets. Ca ne sert à rien si la machine est trop lente pour les traiter (effet d'avalanche). Et ça ne sert à rien si elle est assez rapide pour le faire (tampons vides).
      - [^] # Re: Pile réseau : problème de droits d’auteur
        
        Posté par Joris Dedieu (site web personnel) le 27 juillet 2011 à 13:13. Évalué à 6.
        
        Le fait que les réglages par défaut ne soient pas pertinent pour une forte charge réseau est un évidence. La question du savoir faire est aussi essentielle. En général le système qui marche le mieux est celui que tu connais le mieux.
        
        Je ne connais personne qui m'ait montré en vrai un Linux planté à cause de la charge de sa pile réseau. Ni un BSD.
        
        Typiquement tu va faire planter tes systèmes (BSD ou Linux) dans des contextes non pas de débit pur mais en saturant des tables. C'est le principe du SYN FLOOD par exemple. Mais il existe bien d'autres techniques plus élaborées. Les systèmes avec une table de routage complète ou un gros Firewall a état sont sans doute les plus sensibles sur ce point.
        
        Sans parler de plantage franc, tu as aussi un paquet de petites merdes volontaires ou non qui font que ton réseau perds de la vitesse. Il existe par exemple avec du NAT un moyen très simple de faire cela. C'est d'ouvrir des connexions sur ton routeur a destination de toi même.
        
        En ce qui concerne la swap, de mon expérience, elle ne sert pas a grand chose sur ce type de machines. Si la mémoire est saturée, tu es déjà mort. J'ai également constaté que pour l'heure et malgré des efforts prometteurs en ce sens, le smp est inutile voir nuisible pour du réseau pur.
        
        Enfin en ce qui concerne les cartes, une intel pro1000 quelconque associé a du pooling me semble être le meilleur choix. Je n'ai par contre pas remarqué de différence notable d'une variante à ļ'autre dans cette gamme.
        
        [^] # Re: Pile réseau : problème de droits d’auteur
        
        Posté par Kerro le 28 juillet 2011 à 00:33. Évalué à 2.
        
        Je ne suis jamais arrivé à faire planter en remplissant des tables. Peut-être que je n'ai pas la charge nécessaire. Mais surtout je n'ai jamais eu le besoin de tester à ce point.
        
        J'imagine tout de même mal les ordres de grandeur. Que nommes-tu un gros firewall ?
        Et en quoi une grosse table de routage pose-t'elle problème ? Elle prends de la place, mais de manière fixe non ?
        
        Pour le SMP ça fait longtemps que je n'ai pas mesuré, mais je te suis pour ce qu'il en était il y a quelques années. Actuellement je ne suis pas certain que ce soit toujours le cas.
        Et pour le pooling c'est un truc tout bête que j'avais lu il y a longtemps. Je n'y aurais jamais pensé, et clairement c'est mieux (sous fort débit uniquement, sinon c'est idiot). Une carte pas chère tourne aussi bien qu'une très chère lorsqu'on parle de forte charge. Et lorsqu'on n'a pas de forte charge... ben la différence est négligable :-)
        
        [^] # Re: Pile réseau : problème de droits d’auteur
        
        Posté par Joris Dedieu (site web personnel) le 28 juillet 2011 à 10:37. Évalué à 4.
        
        Je ne suis jamais arrivé à faire planter en remplissant des tables. Peut-être que je n'ai pas la charge nécessaire. Mais surtout je n'ai jamais eu le besoin de tester à ce point.
        
        Normalement, c'est assez simple a faire avec hping en générant des ips / ports aléatoires.
        
        Que nommes-tu un gros firewall ?
        
        Une machine pouvant tenir 500 mb, avec un bon millier de règles et une centaine d'ip derrière.
        
        Et en quoi une grosse table de routage pose-t'elle problème ? Elle prends de la place, mais de manière fixe non ?
        
        Typiquement les grosses tables de routages sont injectée via bgp. Il faut ensuite souvent rajouter de l'ospf pour le routage local et quelques routes statiques au cas ou.
        
        Un table de routage complète c'est plus de 360000 routes. Si tu te fais bien flooder, ta machine peut se retrouver rapidement incapable de décider quoique ce soit.
        
        J'ai également constaté que la nature du trafic influe beaucoup. Dans mon cas, il s'agit d'un trafic avec beaucoup de connexions pour peu de données.
# WiFi Broadcom 4312-lp-phy (4315) enfin pris en charge ?

Posté par antistress (site web personnel) le 27 juillet 2011 à 03:39. Évalué à 2.

Il semblerait d'après ce post [1] que la puce WiFi Broadcom BCM4312 802.11b/g [14e4:4315] soit prise en charge par cette nouvelle version du noyau.
Je n'ai rien lu d'officiel à ce sujet, quelqu'un peut-il confirmer ou infirmer ?
Cette puce équipe par exemple les Netbooks Dell Mini 9
Merci d'avance

[1] http://techpatterns.com/forums/about1897.html
- [^] # Re: WiFi Broadcom 4312-lp-phy (4315) enfin pris en charge ?
  
  Posté par ZeroHeure (site web personnel) le 07 août 2011 à 13:27. Évalué à 2.
  
  Très possible. La page officielle du pilote wifi b43 indique qu'un support partiel existe depuis le noyau 2.6.33: http://linuxwireless.org/en/users/Drivers/b43 (pose la question sur leur mailing liste pour être sûr)
  A défaut tu peux te rabattre sur le pilote officiel Linux Broadcom (non libre) http://www.broadcom.com/support/802.11/linux_sta.php
  
  "La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
# Merci !

Posté par JEANPOL_PARLFOR le 27 juillet 2011 à 21:51. Évalué à 0.

Merci beaucoup pour cette news et le travail associé, toujours autant instructif ! :)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.