Sommaire
La phase de test
RC-1
La version RC-1 a été annoncée le 14 juillet par Linus :
Ça fait deux semaines et la fenêtre d'intégration est dorénavant fermée. Si j'ai oublié quelque-chose, hurlez, mais il n'y a rien en attente à ma connaissance.
Cette fenêtre d'intégration était plus petite en terme de nombre de changements que celle de la 3.10, mais nous avons plus de nouvelles lignes. La plupart semblent être en « staging » — un tiers des changements en terme de lignes est « staging » et l'intégration de Lustre en est la principale raison. Nous verrons comment ça finira ; je dois dire que nous n'avons pas une grande expérience sur les systèmes de fichiers à travers « staging ».
Je pense que c'est une fenêtre d'intégration relativement calme, excepté pour celle de Lustre. Nous avons eu des problèmes sur quelques arborescences, et nous avons un débat en cours sur des correctifs stables déclenché par cette période de fusion ; nous devrions donc avoir un sujet de discussion pour le « kernel summit ». Mais dans l'ensemble, je soupçonne que nous devrions commencer à assister au calme estival habituel (excepté pour l'Australie).
Bien que plus petit que la dernière fenêtre d'intégration, ce n'est pas comme si c'était « minuscule », et comme d'habitude je fais uniquement un résumé du rapport de fusion de la -rc1 : comme d'habitude les personnes nommées ici ne sont pas les contributeurs qui ont écrit le code (bien que dans certains cas cela soit vrai), mais les propriétaires des dépôts que j'ai récupérés.
Hey, commençons tous les tests,
Linus
Avant la RC-2
Avant la sortie de la RC 2, Linus se plaint du manque de correctifs. Les développeurs seraient-ils partis en vacances ?
Nous sommes à mi-chemin de la première semaine après la fermeture de la fenêtre d'intégration, et normalement je devrais être en train de me plaindre à propos du nombre de trucs que vous m'envoyez tous, et de vous rabâcher que vous m'avez envoyé quelques conneries à moitié terminées pendant la fenêtre d'intégration, qui auraient probablement dû attendre jusqu'à la prochaine version.
Mais non. Tout le monde a préféré commérer autour de la fontaine, et j'ai eu une ou deux demandes d'intégration par jour de gens qui sont heureusement inconscients (ou trop intelligents pour s'impliquer) sur l'ensemble « flame fest ».
Je suis acariâtre et difficile. Envoyez-moi trop de choses, et je crie. Envoyez-en moi trop peu et je crie. Parce que je suis la « Boucles d'or » du développement du noyau, et je veux que mes demandes d'intégration soient bien, tout simplement. Et clairement toute l'énergie a été épuisée dans la discussion, pas dans le travail.
Ouste. Retournez à vos bureaux. Ne vous rassemblez pas tous dans la salle de pause.
Linus
PS : Ou peut-être vous êtes simplement professionnels et vous comptabilisez votre temps, et tout le monde a l'intention de m'envoyer son travail au moment de pointer, le vendredi à 17 heures. Mais ce n'est pas ce qu'on ressent.
RC-2
La deuxième RC a été annoncée une semaine plus tard par Linus :
Donc ça fait une autre semaine, et la -rc2 est là.
Les changements sont un peu bizarres, car en vrac, 95 % d'entre eux concernent uniquement la suppression du pilote « staging » CSR qui n'attirait personne, de sorte que le diffstat (et le dirstat en particulier) n'est pas très intéressant ni lisible à cause de la suppression du pilote qui éclipse pratiquement tout le reste. Mais j'avoue aimer voir de la suppression de code.
Pour le reste des changements, une partie notable concerne la suppression des marques _cpuinit dont les gens ont convenu qu'elles apportaient plus de difficultés que de gain à maintenir. Nous avions au préalable rendu les marqueurs inopérants, de sorte qu'ils n'aient pas d'importance pour la génération de code, et ici, pour la rc2, ils peuvent être effectivement supprimés.
Résultat : nous avons deux événements distincts qui génèrent beaucoup de bruit au sein de la liste des changements, mais ils ne sont pas très intéressants, et ne rendent la lecture de celle-ci que plus difficile.
Si l'on ignore le bruit de fond sus-mentionné, il y a une ou deux choses à noter à propos de la rc2. Je pense que la plupart des changements sont des correctifs gentils, mais je voulais donner un peu plus d'importance à deux points que voici :
(a) le drapeau O_TMPFILE, nouveauté de la 3.11, a subit quelques nettoyages d'ABI / API (et également quelques correctifs d'implémentation), mais je pense que nous avons fini maintenant. Donc si vous êtes intéressés par le concept de fichiers temporaires anonymes, allez de l'avant et testez-le. L'absence de nom permet non seulement de se débarrasser de concurrences / complications avec la génération de fichier, mais ça peut aussi rendre le tout plus efficace puisque vous n'avez pas les opérations d'annuaire qui peuvent causer de la sérialisation d'entrées-sorties, entre autres.
(b) nous avons eu un changement de dernière minute sur la façon dont la gestion du rétroéclairage ACPI est faite sur certaines machines, et bien que ce genre de chose ne devrait pas vraiment être fait en dehors de la fenêtre d'intégration, j'ai fini par l'intégrer quand même. Mais je voudrais vraiment avoir des gens qui testent cette chose, en particulier sur les ordinateurs portables munis d'une carte graphique Intel. Ça ne devrait toucher (et améliorer les choses avec de la chance) que les ordinateurs les plus récents dont le BIOS a été conçu pour Windows 8, mais bon, plus il y a de tests, mieux c'est. La gestion du rétroéclairage a été difficile auparavant, donc je le mentionne explicitement.
Quoi qu'il en soit, en dehors de ces deux problèmes, je pense que le reste est assez normal pour une rc2. Ça a commencé un peu lentement, mais je pense que ça a fini normalement. Outre les trucs déjà mentionnées, nous avons des choses sur le DRM (radeon en particulier), quelques corrections de pilotes, mises à jour s390/mips/arm/x86, les pilotes audio, des corrections ext4/btrfs, bla bla.
La liste courte des modifications depuis la -rc1 est en pièce jointe.
Linus
RC-3
La troisième RC :
À nouvelle semaine, nouvelle -rc.
S'il vous plaît, oubliez ce que je vous ai dit la semaine dernière sur le fait de retourner au travail. Vous l'avez fait. La -rc3 a environ 50 % de changements de plus que la -rc2. C'est en partie dû au fait que quelques gens ont manqué la rc2, mais aussi que des gens m'en ont envoyé plus. S'il vous plaît, arrêtez. C'est l'été. C'est agréable à l'extérieur. Emmenez les enfants à la piscine ou autres. Envoyez-moi seulement des correctifs de régressions.
Sinon, je vais devoir recommencer à crier sur les gens.
Quoi qu'il en soit, souvenez-vous comment j'ai demandé aux gens de tester les modifications du rétroéclairage dans la rc2 parce que des choses comme ça ont vraiment de mauvais antécédents ? Yep. Tout ça a été annulé. Cela a corrigé les choses pour certaines personnes, mais ça a régressé pour les autres, et nous ne faisons pas « un pas en avant, deux pas en arrière ». Mais n'ayez crainte, nous avons des super gens qui regardent ça.
Le support de la crypto « crc t10 dif » a été annulé aussi parce que ça pose des problèmes avec l'infrastructure d'initrd.
Mais l'essentiel ici concerne les mises à jour de pilotes de blocs (drbd, rsxx, xen, bcache, libata) et les changements de DRM (principalement qxl, mais il y a aussi des changements sur le « big tree » : radeon, intel, nouveau). Et enfin, quelques pilotes — usb, scsi, pincontrol, etc.
Il y a également des mises à jours classiques pour certaines architectures (principalement pour alpha, arm et powerpc).
Le rapport complet des changements depuis la rc2 est en pièce jointe. C'est tellement gros que j'ai débattu le fait de faire uniquement un rapport d'intégration dans le style « période d'intégration », mais peut-être que les gens apprécient ce genre de détails ?
Linus
RC-4
La quatrième RC a été annoncé avant la nuit du 4 août :
C'est à nouveau ce moment de la semaine…
"Appliquez 339 correctifs, qu'obtenez vous au final ?
Plus âgé d'une semaine et un peu plus redevable.
Saint Pierre ne m'appelle pas, car je ne pourrais venir à toi
Mon âme, au magasin de la compagnie, je la dois "
J'avais espéré que les choses commenceraient à se calmer, mais la rc4 est à peu près de la même taille que la rc3. Ceci dit, les correctifs semblent un peu plus épars et moins intéressants — ce qui est une bonne chose. L'ennui, c'est bien. Maintenons les choses ainsi et essayons de faire moins de correctifs pour la rc5, d'accord ? Parce que nous avons parcouru la moitié du chemin maintenant, et je ne souhaite vraiment voir que des corrections.
Nous avons des mises à jour d'architectures (arm et parisc), mais la majorité concerne des pilotes (surtout du réseau, usb et drm). Il y a également des changements profonds au niveau réseau. Et les mouvements du code printk semblent importants si vous n'utilisez pas git renames (c'est-à-dire comme les correctifs que j'envoie).
Linus
RC-5
La cinquième RC est sortie le 11 août et Linus s'amuse avec la sortie de Windows 3.11 :
Malheureusement, la numérologie ne fonctionne pas si bien, et alors que sortir la version 3.11 aujourd'hui serait une heureuse coïncidence (Windows 3.11 sortait ce jour même, il y a vingt ans), ce ne sera pas le cas.
À la place, nous avons une 3.11-rc5.
Cette dernière montre des signes d'accalmie et est nettement plus petite que les précédentes RC (autant en nombre de changements, qu'en taille des dits changements). Espérons seulement que ce n'est pas uniquement un coup de chance.
Il semblerait qu'il n'y ait aucun changement majeur. Les changements touchant radeon sont les plus notables, mais la majorité d'entre eux ne concerne que la gestion dynamique de l'énergie qui est désactivée par défaut… Mis à part ça, quelques corrections média, des mises à jour d'architectures, quelques petites mises à jour au niveau systèmes de fichiers, etc. Rien ne sort vraiment du lot.
Linus
RC-6
La version RC-6 a été annoncée le 18 août par Linus :
La semaine a été plutôt calme, et les RC s'amenuisent, ce qui me satisfait.
Bien sûr, nous avons rencontré un bogue intéressant et bruyant dans le code d'invalidation de la TLB, mais c'était un bogue plus ancien et apparemment vraiment difficile à le reproduire en pratique. Ceci dit, cela pourrait expliquer quelques SIGSEGV aléatoires, etc. Ainsi si vous avez vu un comportement étrange, peut-être que vous êtes tombé dessus, et la RC6 corrigera cela. On touche du bois.
Sinon, ce sont plutôt des changements aléatoires : réseau, pilotes, usb, son et quelques corrections pour les systèmes de fichiers. On retrouve également des mises à jour architecturales pour x86, ARM et m68k. Mais c'était vraiment calme. Le résumé ci-dessous donne les détails pour ceux qui sont intéressés.
Puisque les statistiques de cette rc étaient ennuyeuses, j'ai commencé à regarder des chiffres plus impressionnants. Cela fait maintenant huit ans que l'on utilise git, et on a effectué plus de 400 000 changements durant cette période. C'est intéressant (du moins pour moi), puisque à l'époque où l'on utilisait BK (BitKeeper, de 2002 à 2005, NDT) on s'approchait de la limite des 65 000 changements en 3 ans d'utilisation. Cela fait donc longtemps que l'on a pulvérisé cette limite.
Qu'en est-il de ces 400 mille changements ? Ils tiennent tous dans un fichier empaqueté de 575 Mio (plus un index de 85 Mio). Après, c'est en forçant plus sur la compression du paquet de fichiers que la plupart des personnes doivent le faire, mais je pense qu'il est intéressant de voir comment 8 années d'historique de développement actif ont la même taille que l'arbre des sources brut. En fait, je pense qu'il vous faut plus d'espace libre pour les fichiers objets lors de la compilation que l'espace nécessaire au stockage de tout l'historique.
J'essaierai de me souvenir de faire des statistiques plus intéressantes et pertinentes pour la sortie de la rc7, parce que cela coïnciderait avec le 22e anniversaire de l'annonce initiale de Linux sur comp.os.minix.
Comme le temps passe vite lorsqu'on s'amuse…
Linus
RC-7
La version RC-7 a été annoncée le 26 août sur Google+ par Linus :
Bonjour à tout le monde ici-bas utilisant Linux,
Je fais un système d'exploitation (libre) (juste un passe-temps, même si c'est important et professionnel) pour les clones d'AT 486+ et presque tout le reste ici bas sous le soleil. Le brassage est en cours depuis avril 1991 et ce n'est pas encore prêt. J'aimerais avoir des retours sur les choses que les gens aiment/détestent dans Linux 3.11-rc7.
J'ai initialement porté bash (1.08) et gcc (1.40) mais les autres ont repris l'espace utilisateur et ça semble fonctionner. Ça indique que je vais avoir la version 3.11 finale d'ici une semaine et j'aimerais savoir quelles fonctionnalités la plupart des gens voudraient. Toutes les suggestions sont les bienvenues mais je ne promets pas que je les implémenterai :-)
Puis il rajoute en commentaire :
Ouais, je ne veux vraiment pas avoir de demande de fonctionnalités en cette fin de version rc…
Mais ça fait 22 ans aujourd'hui depuis cette annonce et j'aimerais que les gens testent le noyau actuel 3.11-rc7 que je viens de téléverser aux emplacements habituels.
Linus
Les nouveautés
Zswap
Zswap est une fonctionnalité du noyau qui fournit la compression du cache pour le swap. C'est en développement depuis longtemps et le code est enfin disponible dans le développement principal du noyau Linux.
Zswap prend les pages qui sont dans le traitement d'évacuation du swap et essaie de les compresser dans un groupe de mémoire vive allouée dynamiquement. Et si l'espace ainsi gagné est suffisant, des écritures sur disque sont évitées. Zswap échange ainsi cela par des cycles processeur pour réduire potentiellement des écritures et lectures en swap. Cet échange peut améliorer de façon significative les performances si les lectures du cache compressé sont plus rapides que les lectures du swap.
Pour plus de détails sur Zswap.
Compression LZ4 pour le noyau
LZ4 est un outil de compression très rapide par rapport à Gzip, bzip2, LZMA ou LZO. Il utilise l'algorithme de compression LZ77 et LZ78 (pour plus de détails sur le fonctionnement de LZ4 voir ici). Le nouveau noyau prend en charge la compression LZ4 du noyau. Il permet ainsi de faire un démarrage plus rapide du noyau Linux. Cette prise en charge est actuellement possible seulement pour l'architecture ARM. Il n'est pas à exclure que cela soit étendu à d'autres architectures dans une prochaine version.
Plus de détails sur LZ4 pour le noyau.
Sécurité : option O_TMPFILE
La nouvelle option O_TMPFILE pour les appels systèmes open() et openat() permet aux systèmes de fichiers d'optimiser la création de fichiers temporaires (fichiers qui n'ont pas besoin d'être visibles dans le système de fichiers). Lorsque l'option O_TMPFILE est présente, le nom du chemin fourni est seulement utilisé pour trouver le répertoire le contenant (et donc le système de fichier où le fichier temporaire devrait être). Ainsi, par exemple, les programmes utilisant O_TMPFILE devrait avoir moins d'inquiétudes concernant la vulnérabilité des attaques avec des liens symboliques.
Rapid Start
Matthew Garret, un spécialiste d’UEFI, est actuellement en train de regarder comment mettre en œuvre Rapid Start sous Linux.
Rapid Start est une technologie Intel ayant pour but de permettre à un système de sortir d'un profond sommeil en 5 ou 6 secondes, c'est-à-dire plus rapidement que la traditionnelle hibernation et bien plus efficacement qu'une réelle extinction de la machine. Elle mémorise dans une SSD dédiée le contenu de la RAM.
Au niveau technique, Rapid Start utilise un micrologiciel qui copie le contenu de la mémoire vive sur une partition spéciale d'un disque SSD avant d'entrer en sommeil profond, et inversement remet son contenu dans la mémoire vive lors du réveil. La différence avec l'hibernation classique est que le micrologiciel se situe dans le BIOS UEFI, permettant de gagner quelques secondes (pas de GRUB etc).
Matthew Garret a mis en place un changement permettant de mettre en œuvre ce mécanisme. Évidemment, il faudra aussi mettre en œuvre cette avancée en espace utilisateur. Les développeurs de la distribution Ubuntu commenceraient à travailler sur cela. Il est probable que cela soit fonctionnel pour la prochaine version LTS qui sortira en avril.
Pour plus de détails, voir son blogue.
Renesas R-Car
Pour finir concernant les nouveautés, nous pouvons noter l'arrivée d'un nouveau pilote graphique Renesas R-Car qui est une puce à quatre cœurs ARM Cortex-A9. Cette puce est utilisée pour les systèmes embarqués dans les voitures haut de gamme.
Les améliorations
Architectures
ARM
De nombreux changements de ce nouveau noyau ont concerné les architectures ARM. On peut citer notamment :
Voir plus de changements.
AArch64
Vous avez peut-être déjà entendu parler de l'architecture ARM 64 bits ? C'est une architecture qui n'existe pas encore physiquement, mais seulement virtuellement. Il est maintenant possible de virtualiser cette architecture en utilisant KVM ou XEN. Au delà de cette possibilité de virtualisation, cette architecture a reçu des améliorations. Elle peut monter des partitions Hugetlbfs et utiliser des huge pages transparentes. Enfin il est à noter une amélioration au niveau du vidage de la mémoire disque du noyau (Cache flushing).
Pour plus de détails.
Cryptographie
Voici la liste des changements concernant la cryptographie :
- prise en charge du sha224 et sha384 pour les processeurs utilisant le jeu d'instruction SSSE3 ;
- API du LZ4 ;
-
Instruction PCLMULQDQ pour accélérer CRC T10 DIF ;
- prise en charge du co-processeur DCP de Freescale.
Audio
Rien de révolutionnaire dans cette section. Seulement des prises en charge de nouveaux périphériques. Par exemple :
-
prise en charge de la radio pour la carte MediaForte M56VAP ;
- ajout du pilote pour le convertisseur numérique USB vers S/PDIF M2Tech hiFace qui se charge d'améliorer la transmission des données audio ;
- amélioration de la prise en charge du pilote Intel Haswell.
Pour plus de détails.
Pilotes graphiques
Intel
Haswell est la nouvelle micro architecture, sortie début juin, qui succède à Sandy Bridge. Les premiers patchs pour son support datent d'Août 2012, 10 mois avant la sortie officielle du microprocesseur. Son support a été déclaré stable fin Novembre 2012 à l'occasion du noyau 3.8, soit un peu plus de 7 mois avant sa sortie. Il s'est encore amélioré dans les sorties suivantes. On peut donc dire qu'Intel fourni un support exemplaire car il permet aux distributions grand public telles qu'Ubuntu de pouvoir prendre en charge les nouveaux processeurs graphiques Haswell dès leur sortie sans avoir besoin de mettre à jour le noyau ou de rétroporter les modifications dans le noyau de la distribution.
Les nouveautés apportées au support d'Haswell dans cette version sont :
- Intermediate Pixel Storage (IPS) permet de réduire le nombre de fois où le moteur graphique réveille la mémoire pour lire les pixels. Ainsi cela fait diminuer la consommation électrique ;
- Frame-Buffer Compression (FBC) permet aussi d'économiser de l'énergie.
Pour plus de détails, voir ces courriels sur dri-devel en mai et en juin.
NVIDIA (pilote Nouveau)
Cette nouvelle version marque l'arrivée du support de VP2, groupe de moteurs de décodage vidéo matériel pour les Geforce 8 et 9. Cette fonctionnalité a été développée par un ancien contributeur revenu travailler sur Nouveau, Ilia Mirkin. Son travail vient compléter le support déjà existant de VP4.2 et VP5, moteurs de décodage vidéo matériel respectivement pour les cartes de la famille Fermi et Kepler, qui permettent le décodage matériel des vidéos encodées en MPEG1/2 ou H264. La prochaine version de Linux verra l'ajout du support de VP3 et VP4 ce qui complétera le support du décodage vidéo pour pratiquement toutes les cartes Geforce 8+.
Pour utiliser le décodage vidéo, il est encore nécessaire d'utiliser les microcodes de NVIDIA. Comme leur licence ne permet pas leur redistribution, c'est à l'utilisateur de faire l'effort de les installer. Cette opération a longtemps nécessité de faire une MMIOTrace (opération assez compliquée) mais Ilia a simplifié la procédure en permettant l'extraction automatique des microcodes directement depuis le pilote propriétaire de NVIDIA. Si vous utilisez ArchLinux, il vous suffit d'installer le paquet nouveau-fw pour en bénéficier. Pour les autres distributions ou si vous souhaitez en savoir plus, vous pouvez visiter la page de wiki dédiée au décodage vidéo qui vous indiquera le niveau de prise en charge actuel de chaque carte, la version logicielle de chaque composants que vous devez avoir ainsi que la procédure à suivre pour extraire et installer les microcodes, mais aussi, pour finir, comment utiliser l'accélération vidéo VDPAU.
Cette nouvelle version a aussi permis de corriger bon nombre de bugs et plantages. Ces bugs étaient majoritairement liés à l'imperfection du microcode libre qui permet d'effectuer le changement de contexte dans la carte, processus indispensable à l'accélération 3D dans l'architecture actuelle de Nouveau. L'amélioration de ces microcodes a rendu stable le (très problématique) chipset NVD9. La tâche de débogage est encore en cours ce qui devrait augmenter la fiabilité et la cohérence du pilote dans la prochaine version.
Pour finir, le support initial pour les NVD7 a également été ajouté.
ATI/AMD (pilote radeon)
Le pilote radeon a provoqué l'étonnement lorsque Alex Deucher, développeur chez AMD, a publié un jeu de 165 patchs pour ajouter un support complet de la gestion d'énergie pour les cartes de la famille r6xx à SI (Southern Island). Comme la gestion d'énergie est un sujet complexe, voici une petite présentation sur les différents concepts présents.
La consommation des MOSFET
À l'échelle la plus basse, une carte graphique est majoritairement composée de transistors de type MOSFET. Ces transistors sont une des causes principales de la consommation énergétique. Cette consommation est découpée en deux parties:
- la consommation statique : à force de miniaturiser les transistors, ceux-ci ne sont jamais complètement bloquants, il y a donc un courant de fuite lorsque le transistor est ouvert. Ce courant (Ileak) doit être multiplié avec la tension d'alimentation (Vdd) pour calculer la consommation statique (Pstatic = Vdd * Ileak).
- la consommation dynamique : cette consommation est liée au fait de changer l'état (ouvert/fermé) d'un transistor. Elle est généralement approximée par 3 facteurs, la fréquence de changement d'état (f), la tension d'alimentation (Vdd) au carré et la charge capacitive (C) qui empêche le changement d'état (Pdynamic = f * Vdd² * C).
Les 3 méthodes pour diminuer la consommation des MOSFET
En se basant sur ces équations, une des premières approches pour réduire la consommation énergétique est de diminuer la tension d'alimentation (Vdd). Cependant, si l'on diminue trop la tension d'alimentation, la charge capacitive (C) vient empêcher le changement rapide d'état ce qui contraint à diminuer la fréquence de fonctionnement de la carte et qui affecte donc les performances. Il faut donc adapter dynamiquement la fréquence ainsi que la tension d'alimentation en fonction de la charge du GPU. Cette technique s'appelle le Dynamic Voltage/Frequency Scaling et utilise généralement les compteurs de performance matériels pour déterminer le niveau de performance requis.
Une autre solution pour diminuer la consommation énergétique est de couper l'horloge des blocs de transistors qui ne sont pas actuellement en cours d'utilisation. Cela permet de rendre nulle la consommation dynamique au prix d'une augmentation de la complexité de l'arbre d'horloge. Cette technique s'appelle le Clock Gating et peut théoriquement n'avoir aucun impact sur les performances.
Pour finir, la solution la plus efficace pour diminuer la consommation énergétique est de couper l'alimentation des blocs inutilisés de la carte. Cette technique, appelée Power Gating, a pour mérite de couper totalement la consommation énergétique au prix de la perte des informations stockées dans les registres des blocs power-gatés. Il est donc nécessaire de sauvegarder le contexte d'un moteur d'exécution avant d'utiliser le Power Gating et de recharger le contexte après son utilisation. Ces opérations sont lentes ce qui limite la fréquence à laquelle le Power Gating peut être utilisé. Ces opérations sont généralement faites par un microcontrôleur dédié à la gestion d'énergie pour ne pas encombrer le CPU.
Et DPM dans tout ça ?
Pourquoi parler de tout cela ? Tout simplement parce que derrière l'acronyme DPM (Dynamic Power Management), utilisé par AMD, se cache en fait ces 3 méthodes que je viens de vous présenter. Cette gestion d'énergie implémentée par AMD est donc maintenant disponible pour toutes les cartes AMD sauf celles de la prochaine génération (Sea Islands) où le travail a déjà commencé et évidemment sur les vieilles cartes où le DPM n'est pas ou peu supporté par le matériel.
Un premier benchmark sur la RC1 montre une amélioration des performances notamment sur les jeux demandant beaucoup de ressources. DPM peut en effet améliorer les performances de la carte graphique car le code agit sur sa fréquence et ses tensions d'alimentation (technique : Dynamic Voltage/Frequency Scaling). Jusqu'à présent le pilote libre AMD ne modifiait pas ces paramètres, et les valeurs par défaut n'étaient pas forcément celles permettant de profiter de toute la puissance de la carte. Un autre test montre que, sur un échantillon de trois cartes graphiques différentes, on constate une réduction de la consommation en Watts (jusqu'à 40 %) et une réduction de la température (de quelques degrés).
Notons tout de même que DPM n'est pas activé par défaut du fait de la jeunesse du code.
ASPM : Gestion d'énergie pour le bus PCI-Express
Pour rester dans l'énergie, ASPM (Active State Power Management) est une autre fonctionnalité utilisée pour gérer la consommation énergétique des périphériques PCI Express. Cette fonctionnalité introduit deux modes basse-consommation, équivalents des C-States des CPU. Le niveau d'endormissement L0 est sélectionné dès que le lien devient inactif alors que le niveau L1 est sélectionné après une période d'inactivité supérieure. Le niveau L1 permet d'économiser plus d'énergie au prix d'une latence de sortie d'endormissement supérieure.
L'ASPM avait déjà fait parler de lui en 2011 lorsque sa politique d'activation a été modifiée dans Linux pour pallier les crashs rencontrés avec le matériel bogué. Cela s'était traduit par une distribution plus stable pour certains et une consommation énergétique bien supérieure pour certains autres malchanceux. Une meilleure politique d'activation a ensuite été ajoutée dans la version 3.3 de Linux.
Le support de l'ASPM est maintenant géré pour les familles R600 à Southern Islands. C'est-à-dire toutes les cartes récentes sauf la toute dernière génération.
Support des cartes Sea Islands avant leurs sorties !
Comme si l'amélioration de la gestion d'énergie ne suffisait pas, AMD a aussi publié le support du KMS, de la 3D, du décodage vidéos (UVD) et d'OpenCL pour les cartes de la famille Sea Islands ! Outre le fait que le support presque complet pour une famille de cartes arrive d'un seul coup est impressionnant, c'est la première fois (pour Radeon) que cela arrive pour une carte qui n'est pas encore sortie !
En effet, les premières cartes de la famille Sea Islands devraient être disponibles en octobre 2013. Avec un peu de chance, le support de la gestion d'énergie pour les cartes de la famille Sea Islands pourrait être ajouté au prochain noyau Linux et amènera le même niveau de support à cette famille que pour les autres cartes modernes.
AMD a donc rattrapé son retard et on peut supputer qu'il fera de même pour les prochaines familles de cartes. Dorénavant, il devrait être possible d'utiliser le pilote libre dès la sortie du matériel, en utilisant un noyau Linux stable (idéalement toutefois il faudrait qu'AMD prenne encore un peu plus d'avance afin que les différents composants – noyau, pilote, Mesa – soient à jour dans les dernières versions des distributions au moment de la sortie du matériel comme Intel essaye de le faire de son côté) !
Plus d'informations
Pour plus de détails sur les changements, voir ce courriel de dri-devel de juin et et celui-ici de juillet. Il est aussi intéressant de lire l'interview de Jérome Glisse, développeur des pilotes Radeon chez Red Hat pour comprendre les conditions dans lesquelles se fait le développement du pilote libre AMD.
Autre pilote vidéo
Le pilote QXL qui est apparu dans la précédente version a reçu des améliorations : redimensionnement dynamique, possibilité d'avoir plusieurs sorties vidéos et prise en charge de l'hibernation et de la mise en veille.
Systèmes de fichiers
Pas de grosses nouveautés dans les systèmes de fichiers grand public.
ext4
Concernant le système de fichiers ext4, qui est installé par défaut dans la plupart des distributions GNU/Linux, on peut noter beaucoup de corrections de bogues, de nettoyage de code et d’optimisations.
Au niveau des corrections de bogues, il en est une à noter concernant le redimensionnement à chaud des systèmes de fichiers où la taille des blocs est plus petite que la taille d'une page (sur une architecture x86, elle est de 1 Kio. Plus utile, sur une architecture ia64 ou Power, où la taille est de 4 Kio).
Dans la catégorie nettoyage de code, la mise en œuvre de la perforatrice de l'ext4 a été vraiment améliorée et prend maintenant en charge les systèmes de fichiers de type bigalloc. Par ailleurs, Jan Kara a nettoyé de façon significative le nom d'accès du code de demande d'écritures. Enfin la vérification d'erreurs a été améliorée et quelques vérifications de bonne santé du système de fichiers ont été ajoutées.
Concernant les optimisations, il y a deux points importants à mettre en valeur. La première est que ext4_writepages() est maintenant utilisé pour le mode sans allocation différée (nodelalloc), et pour le mode de compatibilité avec l'ext3. La seconde, si vous suivez encore, est que le mécanisme de réduction du cache extent qui a été ajouté dans le noyau 3.9, n'a plus de goulet d'étranglement au passage à l'échelle dû à un verrou tournant (ou spin lock). D'autres optimisations ont permis de réduire l'utilisation du CPU.
Comme vous le voyez, le système de fichiers ext4 est devenu un système mûr spartiate en nouveautés.
Pour plus d'information, voir le pull Git.
Btrfs
Btrfs est en général présenté comme le successeur d'ext4. Mais son but principal est de fournir un système de fichiers pour les nuages qui concurrence par exemple XFS. Peu de nouveautés le concernant, seulement des améliorations de performances, corrections de bogues et du nettoyage de code. Il est tout de même à noter la suppression de la structure btrfs_sector_sum qui permet d'améliorer la performance en écriture sur un disque SSD d'environ 70%. Pour le moment seuls Oracle et Suse supportent ce système de fichiers qui n'est toujours pas en version stable.
Pour plus d'information, voir le pull Git.
Vous pouvez voir sur phoronix une série de tests de performance sur Btrfs selon les options de montage. Cela montre de sacrés différences de performance selon les options que l'on utilise. Il est donc nécessaire de bien étudier cela avant de mettre en place Btrfs sur son infrastructure.
XFS
Concernant le système de fichiers XFS, il y a du nouveau : le travail pour le projet de quotas et de groupe de quotas pour qu'ils soient utilisés ensemble a commencé à être inclus dans le code. Ajout d'un compteur de changement d'inodes et d'une transaction créant une inode.
Par ailleurs, il y a des améliorations de performances lors de la suppression et la création d'inodes, lors de la lecture à l'avance d'une ou plusieurs pages en mémoire cache (readahead buffer), et lors de bulkstat. Enfin il y a des corrections de bogues et du nettoyage de code.
Pour plus de détails, voir le pull Git.
F2FS
F2FS (Flash-Friendly File-System) est un système récent qui a été introduit pour le noyau 3.8. Il a été créé par Samsung pour les mémoires flash de ces téléphones.
Peu de nouveautés le concernant. F2FS gère maintenant les labels de sécurité xattr. Il est maintenant possible de remonter à chaud (avec l'option remount) les partitions F2FS.
Pour finir, on peut noter un test de performance des différents systèmes de fichiers (ext4, btrfs, xfs et f2fs) sur les noyaux 3.9, 3.10 et 3.11 rc1 en utilisant les options de montage par défaut. Il est difficile de troller faire la comparaison entre les différents systèmes de fichiers étant donné que les options de montage peuvent faire varier de façon sensible les résultats. Il est plus intéressant de voir l'évolution de chaque système de fichiers par rapport au noyau.
Lustre
Vous vous rappelez peut-être de Ceph ? Ceph et Lustre sont des systèmes de fichiers distribués et parallèles utilisés sur les grappes de serveurs. Ceph est déjà intégré dans le noyau depuis des lustres (sic). Si on veut résumer grossièrement la différence entre Ceph et Lustre : Ceph est utilisé pour sa haute-disponibilité. Lustre pour sa haute-performance.
La partie client du système de fichier Lustre est maintenant dans la section "staging" du noyau (emplacement pour du code en développement mais n'étant pas encore de qualité suffisante pour les exigences des développeurs du noyau). Cela permettra pour l'utilisateur final une facilité d'installation et de mise à jour. Cependant pour éviter des problèmes de jeunesse de code, il a été désactivé pour cette version.
Autres améliorations
Statistiques
Voici les statistiques des nationalités des développeurs de Linux 3.0 à Linux 3.11 (rc7) pour le nombre de lignes modifiées :
Les nations importantes depuis le noyau 3.0 sont :
- les États-Unis (moyenne : 20 %, en bleu foncé) ;
- l'Allemagne (moyenne : 8 %, en jaune) ;
- la Chine (moyenne : 7 %, en rouge) ;
- l'Angleterre (moyenne : 6,5 %, en vert) ;
- les Pays-Bas (moyenne : 4,8 %, en orange).
La France et la Belgique ont chacune une moyenne de 1,3%.
Il y a quelque chose de remarquable pour ce dernier noyau c'est le pourcentage de la Chine (en rouge) sur le noyau 3.11 (plus de 28% contre moins de 18% pour les États-Unis). Est-ce que les Chinois vont supplanter l'hégémonie américaine sur le noyau Linux ?
Peut-être pas encore. Le système de fichier Lustre a été mis dans le noyau Linux 3.11 par Peng Tao, un développeur chinois. Cette modification représente 85% des lignes modifiés par la Chine. Donc a priori, c'est épisodique.
Il faut tout de même relever le nombre de personnes dont on ne connaît pas la nationalité (moyenne : 24,5%, en noir).
Après de longues années d’absence , l’auteur a remis sa version à jour pour le plus grand plaisir de ses fans !! Voici comment créer un CD bootable Windows 2000, XP x86/x64 et 2003 x86/x64 avec son service pack, à l’aide d’un petit utilitaire qui s’occupera de la décompression et d’intégrer lui-même le service pack afin que vous en ayez le minimum à faire. 
27/08/2013 - David Fossé
