Sortie du noyau Linux 3.6

112
1
oct.
2012
Noyau

La sortie de la version stable 3.6 du noyau Linux vient d’être annoncée par Linus Torvalds. Le nouveau noyau est, comme d’habitude, téléchargeable sur les serveurs du site kernel.org.

Le détail des évolutions, nouveautés et prévisions est dans la seconde partie de la dépêche (qui est sous licence CC BY-SA).

NdA : Merci aux contributeurs ayant participé sur l’espace de rédaction : Sébastien Koechlin, Philip Marlowe, stiffux, M, detail_pratique, samo, baud123, Patrice Genieys, warwick, Olivier Esver, trois_1, Batchyx, ymorin, Grégoire Seux, Benoît, voondo, maboiteaspam.

Sommaire

La phase de test

RC-1

La version RC-1 a été annoncée par Linus le 3 août 2012 :

Et encore une presque-deux-semaines-mais-pas-tout-à-fait phase d’intégration…
Eh oui, cela fait à présent juste un peu plus de 12 jours que la version 3.5 est sortie, et comme je déteste les gens qui m’envoient des demandes d’incorporation à la dernière minute, j’apprécie de leur couper l’herbe sous les pieds alors qu’ils pensaient faire leur demande la veille du quatorzième jour. Si c’était bien ça que vous aviez en tête, dommage pour vous.
Mais peut‐être plus important, cette fois j’ai des voyages prévus, et j’avais le choix entre laisser la fenêtre d’intégration pendant les 14  ours prévus et sortir la version -rc1 depuis l’aéroport (Wi‐Fi gratuit à PDX ! ), ou simplement la clore en avance et ainsi avoir un jour et demi de plus pour, éventuellement, peaufiner les détails avant de partir. J’ai évidemment choisi la seconde option.
J’ai essayé de prévenir à temps les gens qui avaient bien travaillé et avaient beaucoup de choses en attente dans linux-next : ce n’est donc pas une grosse surprise pour certains d’entre vous. Et je ne pense pas que j’ai vraiment loupé de grosses intégrations : si vous regardez le nombre de commits, cette -rc1 est un tout petit peu plus petite que celles des deux précédentes fenêtres d’intégration, mais c’était l’état de linux-next à ce moment. Je pense que c’est un effet « été », même si nous ne parlons que d’une différence de 10 %.

Bon, à propos des trucs intégrés ; comme d’habitude, même le résumé est trop gros pour être publié, cependant il y a la répartition habituelle : environ deux tiers des changements sont dans les pilotes — avec le pilote CSR issu de la branche staging qui est un gros morceau (mon Dieu que ce truc est gros et verbeux, même après la « merdectomie » [NdT : crapectomy]).
Sur la partie non-pilote, un petit peu plus du tiers est de l’architecture (ARM, x86, Tile, MIPS, PowerPC, M68k) et le reste est un partage équilibré parmi les systèmes de fichiers, les changements des includes, le réseau et « le reste ».

J’ajoute ci‐dessous mon « merge shortlog » perso, mais j’aimerais préciser que les personnes listées sont les personnes desquelles j’ai reçu la demande d’incorporation, ce qui n’est pas la paternité, mais seulement la personne à partir de laquelle j’ai reçu le code. Je remarque aussi que mon script shell pour générer cela a loupé des choses comme mon intégration du « patch-bomb » d’Andrew, parce qu’ils diffèrent des fusions git normales. Mais peut‐être que cela donne quand même une espèce d’aperçu des choses qui ont été ajoutées ou mises à jour.

RC-2

C’est le 16 août 2012 que Linus a annoncé la version RC-2 du noyau 3.6 :

Bon, à cause de mes voyages, la version -rc2 est sortie après deux semaines au lieu d’une. Mais elle est là maintenant.
Aussi, et pour la même raison, j’ai ignoré, de manière plutôt agressive, les demandes d’intégration qui semblaient déraisonnablement grosses et effrayantes et qui me faisaient dire « Hmm, cela aurait dû être prêt pour la fenêtre d’inclusion ». Donc, si vous m’avez envoyé une demande d’intégration et qu’elle n’a pas été incluse, demandez‐vous si elle avait l’air grosse et compliquée. Vous pouvez essayer de me la re‐soumettre, mais je vous suggère d’avoir de vraiment bonnes explications quant à pourquoi cela devrait être inclus en dehors de la fenêtre, si ce ne sont pas clairement juste des corrections critiques. Et si ce sont vraiment juste des corrections critiques, mais qu’elles sont malgré tout grosses, dites‐le, et expliquez pourquoi.

Cela dit, ce n’est pas si mal que ça. Oui, j’ai ignoré quelques demandes d’intégration, mais je dois dire qu’il n’y en avait pas tant que ça et le reste était plutôt calme. D’accord, il y a plus de 330 commits, mais sachant que c’est sur deux semaines, c’est un nombre auquel il fallait s’attendre (c’est même un peu faible) pour une des premières -rc. Oui, pour la version 3.5, la -rc2 était beaucoup plus petite, mais c’était inhabituel.

Les statistiques de diffs sont plutôt plates, si ce n’est la partie tcm_vhost (qui était en attente depuis la fenêtre d’inclusion). C’est aussi plutôt bon signe (même si c’est également un signe de mon strict principe « non, je n’inclurai pas ça en dehors de la fenêtre d’inclusion »). De toute façon, des statistiques calmes signifient qu’il n’y a eu nulle part de gros changements, juste quelques petites corrections un peu partout. Les changements les plus remarquables (encore une fois, à l’exception de tcm_vhost) sont les mises à jour de gpu/drm, ainsi que les mises à jour de tools/perf. Sinon, ce ne sont que de petits changements un peu partout.

RC-3

La version RC-3 a été annoncée par Linus le 22 août 2012 :

Une sortie de -rc en milieu de semaine pour coller avec la sortie en milieu de semaine de la version rc2. Cela fait seulement 6 jours depuis la rc2, mais je ne le fais pas seulement pour compenser la longue durée de sortie de la -rc2, je suis également à l’aéroport de San Diego, passant quelques jours ici avant le Kernel Summit.
Une -rc plutôt grosse, probablement parce que les gens se retiennent de me demander des intégrations pendant que je ne suis pas là : il y a donc des demandes en attente pour la -rc3.
Il y a un peu plus de la moitié en pilotes, un quart de mises à jour d’architecture et du vrac — principalement du réseau et du système de fichiers. Une fois le résumé joint, rien ici ne me fait dire « OMG! », ou m’incite à une remarque spécifique. La routine. Testez !

RC-4

La version RC-4 a été annoncée par Linus le 1er septembre 2012 :

Le Kernel Summit étant fini, tout le monde ou presque est reparti de San Diego. Beaucoup de mainteneurs étaient donc absents et ces 10 jours depuis la -rc3 (au lieu de la traditionnelle semaine) ont été plutôt calmes.
Les statistiques sont en toute logique inhabituelles. Il y a 40 % de travail sur les architectures (PowerPC, x86, MIPS, ARM) ; 20 % sur Btrfs (des corrections mineures, parce que j’avais rejeté auparavant une demande d’intégration bien plus grosse) ; et seulement 20 % sur les pilotes, principalement des mises à jour sur DRM (Radeon pour la plupart) et quelques trucs sur libata et drbd.
J’ai joint le résumé, et comme vous pouvez le voir, il est tout sauf significatif. J’espère qu’on entre enfin dans la partie chiante et stable des -rc, et que tout ne va pas se remettre en branle juste parce que tout le monde est rentré chez lui.

RC-5

La cinquième version candidate du noyau a été annoncée par Linus le 8 septembre 2012 :

Ah ! Retour à la normale, une publication par semaine, le truc habituel, quoi.
La 3.6-rc5 est sortie, et tout a l’air assez tranquille. Peut‐être trop tranquille pour ne pas m’attendre au pire, c’est‐à‐dire quand Greg aura réussi à éponger son retard de courriel après le Kernel Summit, et son stage de kayak. Je soupçonne également d’autres développeurs d’avoir été calmes pour les mêmes raisons ou presque.
Je dois bientôt voyager encore, mais si ça reste calme, personne ne s’en rendra compte. Bref, quoi de neuf ? Pas grand chose — ce qu’il y a est bien réparti — et nous sommes revenus à la situation habituelle où le plus gros du travail est représenté par les pilotes : son, MMC, réseau (filaire ou non), PCI, vidéo.
Il y a aussi quelques mises à jour d’ARM (et PowerPC), quelques trucs sur CIFS et des petites corrections éparpillées. Le résumé est joint, constatez par vous‐mêmes.

RC-6

La version RC-6 a été annoncée par Linus le 16 septembre 2012 :

À nouvelle semaine, nouvelle sortie. Et comme je l’avais pensé, la -rc5 était légère parce que tout le monde se remettait du Kernel Summit. La -rc6 est un peu plus grosse : on se rattrape… Cela dit, elle n’est pas énorme non plus et n’a vraiment rien d’effrayant, mais elle n’est pas ridiculement petite.
Les stats sont normales : deux tiers de pilotes et un tiers de mises à jour d’architecture, de systèmes de fichiers (GFS2 et NFS) et un peu de trucs plus au cœur (scheduler, workqueue, etc.)
Testez‐moi tout ça, s’il vous plaît, j’aimerais bien sortir la 3.6 rapidos…

RC-7

Enfin, la version RC-7 a été annoncée par Linus le 23 septembre 2012 :

Hmm. J’aimerais vraiment vraiment dire que c’est la dernière -rc, mais il y a encore quelques trucs en attente… Il y aura peut‐être une -rc8, on verra bien.
Cela dit, ça n’a pas l’air mal. Vous en avez un bon aperçu en lisant le résumé joint : les modifications sont petites — des uni‐et‐quelques‐lignes. Rien n’a l’air inquiétant, même si les changements de powernow-k8/workqueue sont majeurs (mais ils résolvent un bogue et nettoient le code). Je pense que le plus gros patch est le correctif sur le « page table walking pour s390 », et même celui‐là n’est pas énorme.
Donc, si tout va bien et que la semaine qui arrive reste calme, je suppose que je pourrai éviter une autre -rc : croisons les doigts. Bref, lisez le résumé. La plupart des changements sont dans les pilotes (réseau, graphique, Infiniband, bloc…), dans les architectures (s390 et x86) et un peu de vrac (XFS, workqueue, réseau). Bien que ce soit des -rc, n’ayez pas peur de tester : tout devrait être stable. Le plus de tests on aura, le mieux ce sera.

Les nouveautés

Veille et hibernation combinée

Le développeur Bojan Smojver a écrit le patch permettant au noyau 3.6 d’offrir la fonction « suspend to both ».
Comme son nom l’indique, cette nouvelle fonction permet de combiner les fonctions de mise en veille et d’hibernation. De cette façon, le noyau Linux va tout d’abord faire un suspend to disk (sauvegarde du système sur le disque dur), suivi d’un suspend to RAM (sauvegarde du système dans la mémoire vive). On profite ainsi des avantages des deux techniques, puisque la sortie de veille est très rapide et que l’état du système est sauvegardé, même en cas de vidage complet de la batterie.
Cette fonction s’active avec la commande suivante :

echo suspend > /sys/power/disk; echo disk > /sys/power/state

Améliorations de TCP

Deux améliorations importantes de la pile TCP ont été intégrées dans le noyau Linux 3.6.
La première concerne le combat de longue haleine qui a été entrepris contre le « _bufferbloat » (l’engorgement des réseaux du fait de tampons mémoire trop gros). Le nouveau patch se nomme TCP Small Queues et il a été écrit par Éric Dumazet. Il s’agit de limiter la quantité de données qui peut être mise en file d’attente pour un socket. Cela permet de limiter l’engorgement sans se faire entourlouper par tous les tampons de la pile réseau (filtrage IP, contrôle du trafic, etc.).
On peut contrôler la limite en écrivant dans /proc/sys/net/ipv4/tcp_limit_output_bytes, la valeur par défaut étant de 128 Kio.

La seconde amélioration, nommée TCP Fast Open, est l’œuvre de Yuchung Cheng qui travaille chez Google. Il s’agit ici de réduire le temps de connexion lors de l’ouverture d’une session TCP.
La norme actuelle est celle de la poignée de main en trois temps (SYN, SYN-ACK, ACK), mais avec le nouveau patch, on peut établir une session TCP en seulement deux temps. L’idée générale est, pour le client, d’envoyer des données en même temps qu’il expédie son SYN initial. Comment est‐ce possible me direz‐vous ? Eh bien, il faut d’abord que la poignée de main en trois étapes ait déjà eu lieu au moins une fois. À cette occasion le client et le serveur vont échanger un cookie qui leur permettra de se reconnaître ultérieurement. Lors de leurs conversations ultérieures, le client pourra ainsi envoyer sa demande en même temps que son SYN et le serveur lui renverra le SYN-ACK, puis les données demandées, avant même d’avoir reçu le ACK final.
Toute cette mécanique est parfaitement bien décrite dans l’article LWN consacré à TCP Fast Open.
Pour l’instant, seul le code concernant le client a été intégré au noyau 3.6. Les patches portant sur la partie serveur seront intégrés par Yuchung Cheng dans le 3.7.

Suppression du cache de routage IPv4

Le cache de routage IPv4 était présent depuis un bon moment dans le noyau, puisqu’il était déjà présent dans le noyau 2.4.0. L’idée de départ était simple : lorsque le noyau reçoit ou veut émettre un paquet IP et savoir par quelle carte réseau il doit l’envoyer et à quel routeur (next hop), il effectue (pour simplifier) une recherche dans une table de routage IPv4. Mais, comme cela était lent et que les entrées demandées étaient souvent les mêmes, un cache de routage a été introduit pour permettre d’améliorer les performances, surtout pour les gros routeurs qui traitent des millions de paquets à la seconde.

Ce cache stockait directement la requête (par exemple : « je veux router vers 88.191.250.176 un paquet qui vient de 192.168.1.2 depuis l’interface eth1 ») et la réponse (« passe par eth0 en contactant 192.0.2.1 »), ainsi que des pointeurs vers des paramètres comme la mesure du PMTU ou les statistiques de TCP. Si vous n’utilisez pas encore ce noyau 3.6, vous pouvez consulter votre propre cache de routage IPv4 avec ip route show cache.

Mais rapidement, ce cache a montré des signes de faiblesse. D’une part, il fallait le maintenir à jour et vider périodiquement les entrées devenues trop vieilles, et lorsque la table de routage était changée, il fallait vider ce cache. D’autre part, cela rendait les performances dépendantes du nombre de flux sur le réseau, puisque le cache de routage reflétait les flux utilisés. Si le noyau devait router un million de paquets vers la même destination, alors il n’y avait qu’une seule entrée dans le cache de routage, mais si le noyau devait router un million de paquets vers un million de destinations différentes, alors il se produisait un grand nombre d’évictions du cache de routage. Et ce, même si la table de routage de départ était extrêmement simple et que tous ces paquets devaient, au final, passer par le même prochain routeur. Ce problème était rédhibitoire sur les gros routeurs, qui voyaient passer des millions de flux différents (on parle d’un cache hit de seulement 10 %, donc le cache de routage n’était utile que pour un paquet sur dix). Sur une machine plus modeste, un attaquant pouvait exploiter ce problème pour surcharger la machine, ce qui a posé des problèmes de sécurité dans le passé.

Le travail de David Miller consistant à refondre le cache de routage a duré environ deux ans (l’idée a commencé à émerger après la sortie de 2.6.37) et, dans son courriel récapitulatif, il a tenu à remercier particulièrement Julian Anastasov, Éric Dumazet et Steffen Klassert.
Cela n’a pas été de tout repos, car c’est un changement assez invasif, et que peu de personnes ont participé… À tel point que David Miller a dû pousser une gueulante pour que ses patches soient testés. C’est finalement dans ce noyau 3.6 que les patches ont été intégrés.

Ces patches suppriment le cache de routage, multiplient par deux les performances de la recherche dans les tables de routages classiques, et introduisent un autre cache, plus simple, directement à l’intérieur de l’entrée de routage, pour stocker les informations supplémentaires (PTMU, stats TCP…) qui étaient initialement dans le cache.

Améliorations Btrfs

Une interface permettant de générer un diff entre deux volumes Btrfs a été ajoutée à la panoplie des outils de ce système de fichiers.
Avec Btrfs, il est extrêmement facile de créer un instantané du système à n’importe quel moment (c’est‐à‐dire de capturer l’état global du système de fichiers). Ce qui est moins facile, c’est d’examiner les différences qui existent entre deux instantanés.
Le nouvel outil send/receive (largement inspiré de la fonction équivalente sous ZFS) vise justement à améliorer ce point.
Grâce à cette nouvelle fonction, il est possible de ne sauvegarder que les différences entre les instantanés et, en cas de besoin, de régénérer le système complet à partir de ce diff.
La syntaxe d’utilisation est simple, puisqu’il suffit d’un btrfs send -i oldsnap snapshot pour créer un diff par rapport à oldsnap.

Parmi les autres nouveautés de Btrfs listées dans le courriel récapitulatif de Chris Mason, on peut citer notamment la gestion des quotas sur les sous‐volumes.
Cela permet de gérer l’allocation des blocs et de fixer des limites pour chaque sous‐volume et chaque instantané. Comme l’indique Chris, « c’est tout ce dont a besoin une société proposant de l’hébergement Web pour offrir un sous‐volume à chacun de ses utilisateurs ».

Améliorations dans la gestion de l’entropie

Tout est parti de la publication d’un article inquiétant, écrit par des chercheurs issus de l’Université de Californie. Dans ce papier, des faiblesses étaient signalées dans les clés RSA et DSA de nombreux équipements réseau embarqués. Les chercheurs ont indiqué qu’ils avaient trouvé des clés faibles, issues de tous les systèmes (sont cités GNU/Linux, Windows et FreeBSD), mais ils se sont particulièrement penchés sur le générateur de nombres aléatoires de Linux, afin de l’analyser en profondeur.

À la suite de cette étude, les développeurs du noyau ont décidé qu’il était temps de renforcer les mécanismes de gestion de l’entropie de Linux. Les équipements embarqués ont moins de sources d’entropie que les machines de bureau (les intervalles de frappe clavier, par exemple), et il faut donc dimensionner la fonction en pensant à ces équipements.
C’est Theodore Ts’o qui s’est attelé à ce travail, en collectant les patches des autres développeurs dans une branche spécifique.
Le noyau prend donc désormais en compte diverses sources additionnelles, pour brasser encore plus les réservoirs d’entropie (random pool), comme les numéros de série et les noms des fabricants des périphériques USB, l’adresse MAC ou encore les tables DMI du BIOS.
On peut noter que nombre de ces patches ont été rétroportés sur les noyaux bénéficiant d’un support à long terme.

Pilotes graphiques

Peu de nouveautés sur les pilotes graphiques incorporés au noyau 3.6. Dave Airlie a même écrit dans son courriel récapitulatif qu’il s’agissait de « one of the smaller drm -next pulls in ages » !
On trouve néanmoins quelques patches intéressants, puisque le pilote Radeon gère officiellement par défaut les modes à haute vitesse de PCIe 2.0. C’est un gain en vitesse qui peut être appréciable, et qui n’avait pas été activé jusqu’à présent, à cause de divers bogues.
Il ne reste plus maintenant qu’à travailler sur le PCI Express 3.0…
Du côté de Nouveau, pas de changements, à part des corrections de bogues. L’inclusion d’un gros travail de réécriture effectué par Ben Skeggs, a été reporté au noyau 3.7.
Enfin, Intel peaufine son pilote i915, pas mal de nettoyage, pour encore améliorer les performances d’Ivy Bridge. On note aussi l’ajout de la prise en charge des divers cœurs graphiques des futurs processeurs Haswell.

ext4

Deux changements notables dans le système de fichiers ext4 ont été intégrés au noyau 3.6.
Tout d’abord, une optimisation a été effectuée pour les cas de réécriture en parallèle de données sur le disque (parallel non‐allocating writes). Alors qu’avant, il fallait tenir un verrou i_mutex, le patch de Zheng Liu permet astucieusement d’éviter cette coûteuse opération.
Ensuite, suivant en cela les plans décrits dans cette entrée du wiki ext4, les quotas sur le système de fichiers sont maintenant pris en charge nativement. Alors qu’avant, ces quotas étaient stockés dans des fichiers à part, le patch d’Aditya Kali permet de stocker ces informations user.quota et group.quota en tant que métadonnées dans les nœuds d’index (inodes) du système de fichiers. Tout cela est géré par e2fsprogs et devient actif aussitôt que le montage est effectué.

Gestion de l’énergie sur ATA et PCIe

Intel, par l’intermédiaire des développeurs Huang Ying, Zheng Yan et Lin Ming, a proposé plusieurs patches permettant de mieux gérer la consommation des périphériques ATA et PCIe.
Il s’agit ici d’exploiter au mieux le nouveau mode d’endormissement D3 Cold qui fait partie des spécifications PCI Express 2.0 et ACPI 5.0.
Précédemment, il existait le D3 Hot, mais avec le nouveau mode on économise encore plus, puisque le périphérique est complètement stoppé. En fait, on ne peut plus du tout communiquer directement avec lui, et il faut passer par ACPI pour le réveiller. D’ailleurs, certains périphériques, ceux qui ont des tables ACPI « fantaisistes », ont dû être placés dans une liste noire n’utilisant pas D3 Cold.
Bien entendu, cette économie de consommation sur les périphériques compatibles se paie par un temps de réveil en augmentation. Le noyau doit donc faire jouer son infrastructure de gestion de l’énergie (PM, pour Power Management) afin de prendre les bonnes décisions.
En plus des périphériques PCIe, le sous‐système libata a été également modifié afin qu’il puisse lui aussi tirer partie de D3 Cold. Il est probable que les futures versions du noyau utiliseront ces nouvelles fonctions de la libata pour implémenter l’économie d’énergie sur les lecteurs de disques optiques (ZPODD, pour Zero‐Power Optical Disk Drive).

Restriction sur la création de liens

Afin d’augmenter la sécurité, certaines restrictions sur la création de liens, longtemps controversées, longtemps discutées, ont été intégrées dans le noyau.

C’est Kees Cook qui est l’auteur de ce patch permettant de sécuriser l’utilisation des liens symboliques (symlinks) et des liens matériels (hardlinks). Il s’agit ici de bloquer une vulnérabilité faisant partie de la classe des attaques TOCTTOU (time of check to time of use). Entre le moment où un processus vérifie qu’un fichier existe (le check) et le moment où il l’utilise (le use), on peut interposer un lien symbolique pour diriger le processus victime vers la charge utile. Ces attaques s’effectuent dans un répertoire accessible à tous (souvent /tmp) et elles sont particulièrement graves si le processus abusé est un programme permettant le changement d’utilisateur lors de son exécution (setuid).

En ce qui concerne ces attaques TOCTTOU dans /tmp, les développeurs du noyau ont fait preuve d’une inertie coupable, puisque divers patches existent depuis plus de 15 ans et que la protection est intégrée en standard dans des distributions visant la sécurité, notamment GRSecurity et OpenWall, mais aussi dans Ubuntu depuis près de deux ans. Le patch de Kees réutilise ces idées, ainsi que les conseils judicieux d’Al Viro, le grand manitou du VFS.
Deux nouveaux sysctl ont été introduits afin de permettre de contrôler le fonctionnement de ces restrictions.

Quand protected_hardlinks est mis à 0, alors rien ne change par rapport au comportement habituel. Quand il est mis à 1, alors il est impossible pour un utilisateur de créer un lien matériel s’il ne possède pas déjà des droits en lecture et écriture sur le fichier source.
Même chose pour protected_symlinks. Cette fois, quand on se trouve dans un répertoire accessible à tous, la valeur 1 permet de suivre un lien symbolique, uniquement si celui qui suit le lien est le même que celui qui l’a créé (même uid).

Il est difficile de comprendre pourquoi ces restrictions sur les liens n’ont pas été intégrées plus tôt à la couche VFS du noyau. Les réfractaires pointaient une incompatibilité avec la norme POSIX ou encore un risque de dysfonctionnement de certaines applications. Kees a bien pris soin de préciser que POSIX était assez vague sur ce sujet et que la restriction des liens ne violait donc pas la norme. Quant aux applications, on peut les corriger (le démon at a d’ailleurs été « patché »), donc l’objection ne tient pas.
Il reste à espérer que les développeurs se montreront plus coopératifs à l’avenir et, pourquoi pas, soyons fous, arriveront à se mettre d’accord sur une solution pour empiler les modules de sécurité (LSM Stacking).

En vrac

  • Avec le noyau 3.6, il est maintenant possible de d’utiliser un fichier d’échange mémoire (swap) sur une machine distante via NFS. Cette nouvelle possibilité apporte un choix supplémentaire par rapport au plus classique échange via NBD (Network Block Device). C’est la conclusion d’un long travail de Mel Gorman et Peter Zijlstra. Voir cet article LWN datant de 2011 pour plus de détails.

  • Le développeur Shaohua Li a optimisé le fonctionnement de Linux dans le cas de disques SSD en RAID. Les algorithmes de distribution du travail entre les disques étaient jusqu’à présent basés sur le présupposé qu’il s’agissait de disques durs rotatifs classiques. Shaohua Li a donc proposé de nouvelles stratégies mieux adaptées aux SSD pour répartir les données. Dans certains cas, il observe un gain de débit allant jusqu’à 50 %.

  • Le code cpuidle, celui qui s’occupe de prendre les décisions pour entrer ou pas dans les divers mode d’économie des processeurs, a été amélioré. Il prend désormais en charge les processeurs dont les cœurs ne peuvent pas être gérés séparément. La modif de Colin Cross, un développeur Android, autorise maintenant ce couplage des modes d’économie dans le noyau 3.6.

  • Éric Dumazet a optimisé la lecture de la table /proc/net/unix qui liste tous les sockets locaux ([[UNIX domain sockets]]). Alors qu’auparavant la lecture de cette table avait un coût en O(n²) (complexité quadratique) l’utilisation d’une table de hachage permet de réduire le coût de lecture de manière drastique. Éric signale dans son message de commit que le temps mis à lire une table de 200 000 sockets passe de 520 secondes à seulement 2 secondes.

  • Le nouveau sous‐système VFIO (Virtual Function I/O) a été intégré dans le noyau. Il permet de créer plus facilement des pilotes en espace utilisateur. De cette manière, les machines virtuelles comme KVM peuvent utiliser des pilotes PCI ou PCIe ayant de grandes performances (accès direct à la mémoire DMA) et un fonctionnement sûr (gestion de la mémoire par IOMMU). Voir cet article LWN, la documentation de VFIO ou encore ces tranparents de Jörg Rödel.

  • Toujours dans le domaine des pilotes en espace utilisateur (non, Linux ne devient pas un micro‐noyau !) on peut noter l’arrivée du sous‐système UHID qui propose de gérer les entrées‐sorties des périphériques HID (c’est‐à‐dire les périphériques USB ou Bluetooth) directement en espace utilisateur. Le patch de David Herrmann facilite donc l’écriture de ces pilotes HID, puisque toute la partie de gestion des E‐S peut se faire en espace utilisateur et les données sont envoyées au noyau dans le sous‐système HID classique (voir la documentation).

  • L’outil de traçage perf est maintenant capable d’examiner la partie « uncore » des processeurs Nehalem et _Sandy Bridge. Cette partie regroupe les fonctions qui ne font pas partie des cœurs de calcul proprement dits. On retrouve donc le cache L3, les contrôleurs mémoire, le gestionnaire d’énergie PCU, ainsi que le bus QPI.

  • Le développeur Anton Blanchard (n’oubliez‐pas que « all your base are belong to Anton Blanchard » !) a optimisé les routines de pré‐chargement mémoire pour l’architecture POWER7 d’IBM. S’appuyant en partie sur le jeu d’instructions vectorielles VMX, les patches accélèrent de 17 % le code faisant un usage intensif de copy_page et de 12 % le code faisant appel à l’instruction memcpy.

  • Le pare‐feu Netfilter peut désormais profiter de l’aide de divers programmes en espace utilisateur (les helpers) pour faire du suivi de connexion (connection tracking). Une infrastructure de communication entre Netfilter et ces helpers a été écrite par Pablo Neira Ayuso qui explique dans son patch l’intérêt de ce mécanisme.

  • La gestion du bus CAN (Controller Area Network), très utilisé dans l’industrie automobile, est améliorée dans le nouveau noyau. Le développeur Oliver Hartkopp, employé par Volkswagen, a ajouté la gestion de la nouvelle norme CAN FD qui permet d’envoyer 64 octets de données par trame au lieu de huit. Vous pouvez consulter la documentation ou bien, plus vulgarisé, l’article dédié sur la CAN Newsletter.

  • Le développeur Michael Tsirkin a travaillé sur une micro‐optimisation de la machine virtuelle KVM. Son code porte sur une amélioration des temps de traitement des interruptions (et notamment les EOI). Grâce à ses patches, il a observé une réduction notable du temps passé lors des opérations kvm_entry et kvm_exit (quasi division par deux selon ce banc d’essai).

  • Un autre patch, écrit cette fois par Christian Ehrhardt, vise également à améliorer les performances des machines gérant de nombreuses instances KVM. Le travail porte sur la gestion de l’échange mémoire (swap) dans un scénario où les disques sont sur un SAN. Le code permet maintenant de fusionner les requêtes, ce qui conduit, selon les tests effectués, à un gain en débit compris entre 10 % et 40 %, ainsi qu’à une baisse de la consommation processeur.

  • Les algorithmes de chiffrement symétrique Serpent et Twofish peuvent maintenant, grâce au travail de Johannes Goetzfried, bénéficier d’un code assembleur optimisé pour les instructions vectorielles AVX. Certes, il vous faudra un processeur récent (minimum Sandy Bridge chez Intel et Bulldozer chez AMD), mais le gain est intéressant. Il se limite à environ 6 % pour Serpent, mais peut monter à plus de 30 % pour Twofish, par rapport à l’assembleur x86-64 standard.

Statistiques

En ce qui concerne les statistiques du cycle de développement du noyau 3.6, le site LWN a publié son traditionnel article récapitulatif (disponible en s’inscrivant ou en attendant le 4 octobre).
En termes de patches, le total s’établit à 10 226 (au 29 septembre), alors qu’il était de 10 955 pour le noyau précédent. C’est maintenant devenu une solide habitude que de dépasser les 10 000 patches tous les deux mois et demi.
Environ 523 000 lignes de code ont été ajoutées et 252 000 supprimées, pour un accroissement total d’environ 271 000 lignes. Le noyau 3.6 devrait donc approcher les 16 millions de lignes de code en tout.

Cette fois, ce sont 1 251 développeurs différents qui ont proposé au moins un patch dans ce cycle. Le champion en haut du palmarès est H. Hartley Sweeten avec 460 patches portant sur le nettoyage du sous‐système Comedi (périphériques d’acquisition de données), afin de le faire sortir de la branche -staging. En seconde position, avec 175 patches, on retrouve notre ami Mark Brown, qui était médaille d’or sur le 3.3 et le 3.4. Employé par Wolfson Microelectronics, il continue de travailler sur l’amélioration ou la restructuration des multiples pilotes audio du noyau. Enfin, David Miller apparaît en troisième position dans la liste des contributeurs, du fait de son travail sur la pile réseau et notamment de ses patches de suppression du cache de routage IPv4.

Un autre classement intéressant qui est évoqué dans l’article LWN, est celui des étiquettes (tags) Reported-by. Les développeurs apposent cette étiquette pour garder la trace (et pour remercier) des personnes ayant découvert un bogue et ayant pris la peine de le signaler.
Le premier de ce classement, avec 44 étiquettes, est le développeur Fengguang Wu. Il est particulièrement difficile d’essayer de le concurrencer à ce petit jeu des rapports de bogues, puisqu’il dirige l’infrastructure de build/boot testing mise en place par Intel dans leur Open Source Technology Center.
Je vous invite à aller lire l’article fascinant publié par LWN, qui décrit cette infrastructure de test. Juste pour vous mettre l’eau à la bouche, voici quelques chiffres : plus de 100 instances KVM différentes, sur des machines x86-64 et Itanium, compilation et amorçage du noyau pour chaque nouveau commit venant de plus de 180 branches de développement distinctes. Un total d’environ 30 000 noyaux testés par jour !

Peu de changements sont à noter dans le classement par entreprise (Red Hat et Intel dominent toujours les listes de contributions), mais l’embauche de Greg Kroah-Hartman par la Linux Foundation fait tout de même bouger les lignes.
Annoncé sur son blog par un lapidaire sed -i 's/gregkh@suse.de/gregkh@linuxfoundation.org/g' .addressbook, le recrutement de Greg fait mécaniquement reculer SUSE au classement des entreprises contributrices. C’est surtout en termes de lignes modifiées que Greg apparaît dans le classement, puisqu’il supervise la branche -staging et qu’il peut donc ajouter ou supprimer des pilotes en un seul commit.
Une autre conséquence est la progression de la Linux Foundation dans le classement des étiquettes Signed-off-by (seconde position derrière Red Hat avec 1 278 étiquettes). Ces étiquettes Signed-off-by servent à garder la trace des développeurs ayant approuvé l’inclusion d’un patch, et ils sont donc de bons marqueurs pour connaître les gardiens du noyau. Greg Kroah-Hartman étant l’un des plus prolifiques de ces gardiens, il est clair que la Linux Foundation a fait une bonne affaire en l’embauchant… Et pour le même prix, elle gagne un dieu du skate‐board !

  • # Merci pour cet excellent article

    Posté par . Évalué à  9 .

    patrick_g, tes articles sur la sortie des noyaux Linux sont toujours d'une qualité exceptionnelle, merci aux divers contributeurs de l'aider dans cette tâche.

  • # Merci pour la news

    Posté par (page perso) . Évalué à  6 .

    Veille et hibernation combinée

    Ça me parait être une fausse bonne idée. le genre de fonction qui détruit prématurément une batterie en usant tout ses cycles de charge/décharge.

    On peut en savoir plus sur les améliorations apportées sur les pilotes audio ?

    La video de Greg KH est surprenante, surtout lorsqu'il dit qu'il passe plus de temps sur son skate qu'a programmer ! Ses journées font elle donc plus de 36h ?
    Cela dit, quand on voit ses cernes, je ne suis pas sûr qu'il dorme souvent !

    • [^] # Re: Merci pour la news

      Posté par . Évalué à  7 .

      >>Veille et hibernation combinée

      Ça me parait être une fausse bonne idée. le genre de fonction qui détruit prématurément une batterie en usant tout ses cycles de charge/décharge.

      Il me semble que la technologie des batteries actuelles fait que le vieillissement est linéaire et non pas fonction du nombre de charge/décharge…

      • [^] # Re: Merci pour la news

        Posté par (page perso) . Évalué à  6 .

        Tu as une source ?

        • [^] # Re: Merci pour la news

          Posté par . Évalué à  8 . Dernière modification : le 01/10/12 à 11:24

          J'avais également un doute mais d'après la page Wikipédia sur les batteries de type lithium-ion (les plus répandues) :

          ces batteries vieillissent moins vite lorsqu'elles sont rechargées par des recharges partielles que lorsqu'elles supportent des cycles complets de décharge/recharge

          Donc au contraire, cela semble les préserver.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

          • [^] # Re: Merci pour la news

            Posté par . Évalué à  4 .

            Euh comprends pas là, ce texte justifie la remarque de Christophe Merlet, si tu mets en hibernation, tu préserve la durée de vie de ta batterie car ce sera une recharge partielle, quand tu garde ton ordinateur en veuille et que la batterie se décharge totalement (cas anticipé par l'hibernation et veille combinée) et bien c'est une recharge complète donc pas bon pour ce type de batterie.
            Donc je suis d'accord avec lui: l'hibernation et veille combinée ça encourage la mise en veille jusqu'à décharge totale de la batterie ce qui n'est pas bon pour la batterie.

            L'idéal: hibernation + SSD: ça poutre et ça préserve la durée de vie de la batterie.

            • [^] # Re: Merci pour la news

              Posté par (page perso) . Évalué à  4 .

              Je suis d'accord, il faudrait pouvoir mettre un timer de veille "RAM" après lequel la machine se fout en veille profonde.

              Genre: je ferme l'écran mon ordi portable, il se met en veille "RAM" pendant 2 heures. Si au bout de 2h l'ordi n'a pas été réveillé, on passe en veille "Disque".

              • [^] # Re: Merci pour la news

                Posté par . Évalué à  10 .

                C'est déjà possible.

                man pm-action :

                       PM_HIBERNATE_DELAY [=900]
                           If you are using kernel suspend/resume and invoke
                           pm-suspend-hybrid, this environment variable controls how many
                           seconds the system will wait after going into suspend before waking
                           back up and hibernating. By default, this is set to 900 seconds (15
                           minutes).
                
                

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                • [^] # Re: Merci pour la news

                  Posté par . Évalué à  3 .

                  Intéressant: si on ajoute ça a la mise en sommeil hybride: c'est encore plus intéressant: moins de risque que l'ordinateur surchauffe en cas de problème pour passer de la veille à l’hibernation (puisque l'hibernation est fait au début).

            • [^] # Re: Merci pour la news

              Posté par . Évalué à  3 .

              Je n'ai pas répondu à sa remarque sur le type de veille, juste à sa question sur la technologie des batteries actuelles.

              De toute façon, ça dépend du délai défini entre veille RAM et veille disque ; il me semble que par défaut c'est 15 minutes. Donc à moins d'avoir une très mauvaise batterie, on arrive difficilement à faire une décharge complète en hibernation hybride (surtout en veille RAM)…

              Au passage, ça n'est pas vraiment une nouveauté, je fais ça avec les pm-utils sur un noyau 3.2 depuis un bon moment. À moins que c'était un hack et que c'est maintenant plus propre ?

              Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

            • [^] # Re: Merci pour la news

              Posté par . Évalué à  10 .

              Il faut aussi l'imaginer sur autre chose qu'un portable.
              Sur un pc fixe, ça permet d'être en suspend-to-ram, et si jamais il y a une coupure de courant, tu conserves quand même ta session.
              On peut aussi imaginer que la journée, le PC est en veille pour démarrer + rapidement, et que le soir, on coupe direct la multiprise sans avoir a sortir le PC de veille pour l'éteindre complètement.
              Mais sinon, effectivement, pour un portable, ce n'est peut être pas le top, par contre, pour une machine fixe, je trouve ça plutôt sympa.

              • [^] # Re: Merci pour la news

                Posté par . Évalué à  4 .

                En lisant ton commentaire, je viens de comprendre ce qu'est la mise en veille combinée. Je croyais que c'était la même chose que la veille hybride mais pas du tout :

                • la veille hybride place la machine en veille RAM, puis en veille disque après un délai donné ;
                • la veille combinée prépare le système en veille disque, mais reste en veille RAM une fois l'image copiée.

                Et en effet c'est très intéressant comme fonction. Est-ce que ça existe déjà ailleurs ? Il aurait été intéressant de préciser ça dans la dépêche, pour bien comprendre ce qui existait déjà et l'avancée que c'est.

                Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                • [^] # Re: Merci pour la news

                  Posté par . Évalué à  4 .

                  Si ma mémoire est bonne, c'est ce qui se passe depuis quelques années sur les portables Apple. Et c'est très pratique comme fonctionnalité!

                • [^] # Re: Merci pour la news

                  Posté par (page perso) . Évalué à  0 .

                  Moi je ne vois toujours pas la différence avec pm-suspend-hybrid :

                         pm-suspend-hybrid
                             Hybrid-suspend is the process where first the state of the system
                             is saved to disk - just like with hibernate - but instead of
                             poweroff, the system goes in suspend state, which means it can
                             wakeup quicker than for normal hibernation. The advantage over
                             suspend is that you can resume even if you run out of power.
                             s2both(8) is an hybrid-suspend implementation.
                  
                  
                  • [^] # Re: Merci pour la news

                    Posté par . Évalué à  3 .

                    J'avoue, j'ai eu du mal à le piger donc j'ai encore du mal à l'expliquer.

                    Pour faire simple :

                    • veille hybride : veille mémoire, puis veille disque et extinction ;
                    • veille combinée : veille mémoire et disque en même temps.

                    En gros, la seconde c'est juste une veille mémoire standard avec copie du système en cas de coupure de courant.

                    Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                    • [^] # Re: Merci pour la news

                      Posté par (page perso) . Évalué à  1 .

                      Eh bien, c'est bien ce que fait suspend-hybrid. Il met la RAM sur le disque comme pour un suspend to disk (first the state of the system is saved to disk - just like with hibernate) puis il part en suspend to ram (instead of poweroff, the system goes in suspend state). Si il y a une coupure de courant, on redémarrera avec l'image du suspend to disk. Ensuite, t'as juste la flexibilité supplémentaire de pouvoir mettre un délai entre suspend to ram et poweroff si tu le désires.

                      • [^] # Re: Merci pour la news

                        Posté par . Évalué à  5 .

                        C'est marrant mais dans les faits, ce n'est pas du tout ça que j'observe : quand je mets une machine en veille hybride, elle se met instantanément en veille mémoire, puis elle se réveille au bout du délai configuré pour se mettre en veille disque cette fois-ci (avec les messages qui vont bien à l'écran).

                        Ça vient peut-être des scripts PM de Debian, ou alors du module de veille (j'utilise celui par défaut mais j'ai lu que uswsusp n'avait pas besoin de réveiller la machine pour se mettre en veille disque), mais c'est ce que j'obtiens après test.

                        En tout cas, si la doc dit ça, quelle est donc la nouveauté apportée par ce noyau 3.6 (à part de se synchroniser avec GNOME) ?

                        Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

              • [^] # Re: Merci pour la news

                Posté par . Évalué à  2 .

                Pour le portable, il faut aussi tenir compte du temps d'écriture de la RAM.

                Avec une RAM de 4 Go, ça veut dire attendre environ 30 secondes après la mise en veille (suivant les cas). En effet je pense que déplacer le portable juste au moment où il écrit à grande vitesse sur le disque dur n'est pas une bonne idée…

                Peut-être qu'un système plus intelligent qui copie l'image sur le disque uniquement si le niveau de la batterie est en dessous d'un certain seuil serait une bonne idée ? Par exemple en dessous de 50%.

                • [^] # Re: Merci pour la news

                  Posté par . Évalué à  2 .

                  Il faut savoir que le noyau n'écrit pas tout le contenu de la RAM sur le disque, il purge d'abord les caches afin d'atteindre une certaine taille définie dans le fichier /sys/power/image_size (chez moi, elle est de 2 Go, mais je ne sais pas si ça dépend du système). Donc déjà, ça n'écrit pas forcément 4 Go.

                  D'autre part, certains outils comme uswsusp compressent l'image avant écriture ; les processeurs actuels étant suffisamment puissants pour que ça aille plus vite que d'écrire une image plus grosse, ça permet également de gagner du temps.

                  Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

                  • [^] # Re: Merci pour la news

                    Posté par (page perso) . Évalué à  7 .

                    il purge d'abord les caches afin d'atteindre une certaine taille définie dans le fichier /sys/power/image_size

                    Personnellement, je purge complètement les caches d'écriture ("sync") et de lecture ("echo 3 > /proc/sys/vm/drop_caches") lors de l'hibernation

                    Ainsi, je libère toute la ram "cache" d'un coup, et ne sauve sur le disque que la ram réellement utile (programmes + données).

                    La commande "free" lancée avant et après la purge permet de savoir combien l'on a économisé.

                    • [^] # Re: Merci pour la news

                      Posté par (page perso) . Évalué à  4 .

                      Ça n'a aucun intérêt, le noyau le fait déjà.

                      • [^] # Re: Merci pour la news

                        Posté par (page perso) . Évalué à  1 .

                        Il devrait le faire. Mais ce n'est pas si évident que cela.

                        Sur Debian Testing/Wheezy, et suite à des mises à jour, j'ai remarqué un temps de mise en hibernation plus long qu'à l'accoutumé (et ce, même après un reboot de la machine). Depuis que j'ai rajouté un script qui fait opérations, j'ai retrouvé un temps de mise en hibernation qui soit rapide.

                • [^] # Re: Merci pour la news

                  Posté par . Évalué à  4 .

                  Peut-être qu'un système plus intelligent qui copie l'image sur le disque uniquement si le niveau de la batterie est en dessous d'un certain seuil serait une bonne idée ? Par exemple en dessous de 50%.

                  Il faudrait redémarrer un tas de trucs.

                  Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

                  • [^] # Re: Merci pour la news

                    Posté par . Évalué à  1 .

                    Non :), je ne dis pas d'attendre que ça passe en dessous de 50% pour enregistrer l'image: au moment de la mise en veille, l'ordinateur choisit entre le suspend-to-RAM seule ou la veille hybride d'après le niveau actuel de la batterie. Car la batterie peut facilement tenir plus d'une journée en suspend-to-RAM. C'est donc bien suffisant et j'ai rarement besoin du suspend-to-disk, sauf si la batterie est presque vide.

                    Par contre c'est vrai que l'idée de rester en veille RAM jusqu'à un certain niveau de batterie serait un plus :) Ce serait bien si les batteries pouvaient envoyer un message lorsqu'elles passent en dessous d'un certain niveau pour réveiller le portable, qui se mettrait alors en suspend-to-disk.

            • [^] # Re: Merci pour la news

              Posté par . Évalué à  5 .

              Je pense qu'il ne faut pas imaginer cela comme une alternative à l'hibernation mais plutôt à la veille. C'est comme une veille mais on a toujours notre session même si la batteries s'est déchargée entre temps. Ça n'est pas pire qu'une simple mise en veille (pour la batterie).

              Je suis dans ma tour d'ivoire (rien à foutre des autres, dites moi un truc pour moi), si je ne pose pas explicitement une question pour les 99%, les kévin, les Mm Michu alors c'est que je ne parle pas d'eux.

    • [^] # Re: Merci pour la news

      Posté par . Évalué à  4 .

      il ne reste plus qu'à coder la fonction de réveille au bout d'une heure pour passer en vrai suspend to disk, bien plus rapidement que ne le ferait un cycle complet de réveille+s2d.

      "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

    • [^] # Re: Merci pour la news

      Posté par (page perso) . Évalué à  10 .

      La video de Greg KH est surprenante, surtout lorsqu'il dit qu'il passe plus de temps sur son skate qu'a programmer ! Ses journées font elle donc plus de 36h ?

      Il ne dit pas qu'il passe plus de temps sur son skate, il dit qu'il a commencé « when I was like 8 or 9 years old, it's the only thing I've been doing longer than programming ».

      C'est la seule chose qu'il fasse depuis plus longtemps que programmer, c'est à dire que c'est la seule chose qu'il fasse toujours et qu'il ait commencé plus tôt.

    • [^] # Re: Merci pour la news

      Posté par . Évalué à  1 .

      Pour avoir installé une ubuntu sur un pc portable récent, je peux vous dire que c'est super agréable de voir son bureau en moins de 2s après ouverture de l'écran (idem que sous 7). Quand je vois que sur mon portable de 2009 ça prends presque 10-20s !
      Par contre je n'ai pas testé la vitesse de décharge sous l'un ou l'autre OS, mais je pense que des progrès ont été faits de ce coté là aussi.
      Après s'être habitués à des téléphones ou tablettes qui tiennent entre 1 et plusieurs jours en veilles (tout en restant connectés), on a forcément envi que les PC suivent la marche !

      • [^] # Re: Merci pour la news

        Posté par . Évalué à  5 .

        Les smartphones utilisent de la low power DRAM(LPDRAM ?). Elles sont disponibles en fréquence plus basse et en taille inférieur de 4 fois au DRAM classique (en gros).

        Elle ont un mode rétention qui drain 1000 fois (mille, 3 ordres de grandeur) moins de courant que les DRAM classiques, d'où l'efficacité du suspend 2 ram des smartphone.

        Je regrette d'ailleurs que personne n'est tenté une machine à base d'atom + ssd avec ce genre de LPDRAM.

        "La liberté de tout dire, n'a d'ennemis, que ceux qui veulent se réserver, le droit de tout faire"

  • # petite coquille

    Posté par (page perso) . Évalué à  1 .

    Dans la partie sur le Bus CAN, je pense que c'est Volkswagen et non Wolkswagen.

    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: petite coquille

      Posté par . Évalué à  4 .

      Dans la RC-2, autre erreur :

      c'est voire même un peu faible

      "Voire même" est boulière redondant

      • [^] # Re: petite coquille

        Posté par (page perso) . Évalué à  4 .

        Les deux erreurs sont corrigées. Merci.

        • [^] # Re: petite coquille

          Posté par (page perso) . Évalué à  2 .

          "un cache de routage à été introduit" => a été.

        • [^] # Re: petite coquille

          Posté par (page perso) . Évalué à  3 . Dernière modification : le 01/10/12 à 12:06

          "issues de tous les les systèmes" → "issues de tous les systèmes"
          "one of the smaller drm -next pulls in age" → "one of the smaller drm -next pulls in ages"

          • [^] # Re: petite coquille

            Posté par (page perso) . Évalué à  3 .

            "il est maintenant possible de swapper via NFS": le lien gagnerait à être sur l'information utile: le swap NFS plutôt que "maintenant possible"

            • [^] # Re: petite coquille

              Posté par (page perso) . Évalué à  2 .

              Merci Maxime< et liberforce<, corrigé dans le texte.

              • [^] # Re: petites coquines

                Posté par . Évalué à  6 .

                § Améliorations de TCP :
                mise en queue d'attente -> mise en file d'attente
                envoyer des données en mêmes temps -> en même temps

                § Suppression du cache de routage IPv4 :
                un paquet qui viens de -> qui vient de
                et que tout ces paquets -> tous

                § Améliorations BTRFS :
                pour chaque sous-volume et snapshots. -> et (chaque) snapshot.

                § Améliorations dans la gestion de l'entropie
                le générateur de nombre aléatoire de Linux -> nombres aléatoires
                comme les numéro de série -> numéros

                § Pilotes graphiques :
                à causes de divers bugs -> à cause

                § Gestion de l'énergie sur ATA et PCIe :
                a contribué plusieurs patchs -> a apporté plusieurs patchs (ou autre formulation car on ne contribue rien, on contribue à)

                § En vrac :
                mode d'économie des processeur -> processeurs
                c'est à dire les périphérique USB -> périphériques
                Les algorithmes de chiffrement symétriques -> symétrique

                § Statistiques :
                qui ont contribué au moins un patch -> même punition, contribuer est intransitif donc : ont contribué à au moins…

                Concernant le lien sur les statistiques, il faut peut-être signaler que l'article récapitulatif de LWN nécessite de s'authentifier.

      • [^] # Re: petite coquille

        Posté par . Évalué à  2 .

        "Voire même" est boulière redondant

        Tu veux dire sporadique ?

        • [^] # Re: petite coquille

          Posté par . Évalué à  5 .

          Non ça c'est tout ce qui se passe à la campagne.

          Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur

  • # OpenGL 3.0

    Posté par . Évalué à  7 .

    Ce noyau permet de bénéficier d'OpenGL 3.0 avec le futur mesa 9.0/1 ou depuis le dépôt git de celui-ci, avec les cartes graphiques ATI radeon (R600g).

  • # Je ne vais pas le pleurer le cache de routage..

    Posté par . Évalué à  8 .

    Je me souviens d'un projet où on voulait avoir le basculement le plus rapide possible d'une interface à l'autre en cas de panne et il y avait un problème: on change les route et là .. rien: les paquets sont toujours émis sur la mauvaise interface, après avoir chercher dans pas mal de direction, le coupable était en fait le cache de routage.
    Contournement du problème: "flusher" le cache de routage.

    Dommage que je ne sois plus sur ce projet: je me demande la durée de prise en compte d'un changement de route avec ce nouveau code.

    • [^] # Re: Je ne vais pas le pleurer le cache de routage..

      Posté par . Évalué à  4 .

      Dans les cas usuels, ça ne devrai pas être le cas. Moi quand je change mes routes, tout le cache est déjà flushé par le noyau. Le seul cas ou le cache à besoin d'être flushé manuellement, c'est lorsque la page de manuel de (par exemple) ip rule te dit de le faire.

      Et le problème que j'ai quand je veux changer des routes, c'est plutôt que tout les paquets dans la file de la première interface partent dans /dev/null. TCP s'en fout, mais pas le reste …

      Moi j'avais un autre bug chiant: Le cache dans 3.0 était mal foutu et lorsque tu recevait un ICMP redirect, il était appliqué jusqu'à la fin des temps, même si tu vidait ton cache et tes règles. Vu que maintenant ce bordel se trouve dans l'entrée de table de routage, si y a un problème, alors virer l'entrée de routage et la refaire est suffisant pour se débarrasser des redirections.

      • [^] # Re: Je ne vais pas le pleurer le cache de routage..

        Posté par . Évalué à  1 .

        Dans les cas usuels, ça ne devrai pas être le cas. Moi quand je change mes routes, tout le cache est déjà flushé par le noyau.

        C'est vieux ce dont je parles: noyau 2.4 et j'essayai de baisser à quelques ms le temps de basculement et le timer entre 2 flush du cache des routes étaient à 20ms par défaut (de mémoire), donc un utilisateur 'normal' ne s'en apercevrait pas.

        Une fois que tu comprends le mécanisme pas de problème, mais coté documentation c'était (c'est?) assez pauvre.

        Et le problème que j'ai quand je veux changer des routes, c'est plutôt que tout les paquets dans la file de la première interface partent dans /dev/null. TCP s'en fout, mais pas le reste …

        Comprends pas là? Les pertes de paquets ça arrive, lors d'un changement de route ou autre, donc de toute manière il faut bien un mécanisme de reprise soit fourni par la couche réseau TCP/SCTP soit à faire soit même (le reste).

        • [^] # Re: Je ne vais pas le pleurer le cache de routage..

          Posté par . Évalué à  2 .

          Comprends pas là? Les pertes de paquets ça arrive, lors d'un changement de route ou autre, donc de toute manière il faut bien un mécanisme de reprise soit fourni par la couche réseau TCP/SCTP soit à faire soit même (le reste).

          Dans le cas ou tu fait du téléchargement de grand mère ça ne pose aucun problème. Mais pour tout le reste, dans bien des cas c'est irrécupérable. Par exemple pour le multijoueur ou la voip (ou tout ce qui à une contrainte de délai) si tu perd un paquet, t'est foutu, et le temps que tu t'en rende compte, c'est déjà trop tard.

          • [^] # Re: Je ne vais pas le pleurer le cache de routage..

            Posté par . Évalué à  3 .

            Pour le multijoueur ok, pour la voip je dirais que ça dépend beaucoup du nombre de paquets perdus, le trou peut être quasiment inaudible..

            • [^] # Re: Je ne vais pas le pleurer le cache de routage..

              Posté par (page perso) . Évalué à  2 .

              En visio, l'audio est prioritaire mais les sautes de trames vidéo sont monaies courantes…

              D'ailleurs un truc classique à savoir, forcer le 100 ou le giga sur les ports des commutateurs au niveau des équipements de visio améliore grandement la qualité. Comme quoi, rien que le petit dialogue entre le PC et le switch peux perturber la communication.

          • [^] # Re: Je ne vais pas le pleurer le cache de routage..

            Posté par . Évalué à  0 .

            si tu fais du tcp c'est qu'a priori tu peux te permettre de perdre des paquets.
            en udp c'est un peu plus génant, encore que si le choix s'est fait sur de l'UDP c'est que tu peux te le permettre

            par exemple sur la voip tu peux te permettre de perdre un paquet de temps en temps, perdre 20ms dans une conversation, c'est pas vraiment génant.

  • # Nom de code

    Posté par (page perso) . Évalué à  7 . Dernière modification : le 01/10/12 à 14:07

    Ah zut j'ai oublié de dire que le nom de code du noyau avait changé. On passe donc de "Saber-toothed Squirrel" à "Terrified Chipmunk".
    Il est probable que l'origine du nouveau nom s'explique par ce post Google+ de Linus.

    • [^] # Re: Nom de code

      Posté par . Évalué à  1 .

      ou peut être celui-là (en tous cas pour le terrified)

      • [^] # Re: Nom de code

        Posté par . Évalué à  2 . Dernière modification : le 01/10/12 à 13:03

        Bin non, là c'est une musaraigne. Quelle terreur son chat :)

        • [^] # Re: Nom de code

          Posté par . Évalué à  1 .

          terroriser les musaraignes en bavant, c'est moche.

          • [^] # Re: Nom de code

            Posté par . Évalué à  2 .

            C'est assez surprenant que Minky lui apporte ces animaux vivants. D'habitude les chats les mangent et n'apportent que les viscères à leur humain :)

            • [^] # Re: Nom de code

              Posté par . Évalué à  2 .

              C'est assez surprenant que Minky lui apporte ces animaux vivants. D'habitude les chats les mangent et n'apportent que les viscères à leur humain

              Il parait qu'au début, le chat apporte sa proie morte : c'est pour que tu te nourrisses avec. Ensuite il te l'apporte vivante pour t'apprendre à chasser.

              J'en ai 2 et ils jouent simplement avec… Sauf les [moustiques|papillons|picooz|tout_machin_qui_vole] qui ont généralement moins de 30 secondes de durée de vie une fois repérés.

              • [^] # Re: Nom de code

                Posté par . Évalué à  4 . Dernière modification : le 01/10/12 à 23:42

                Il parait qu'au début, le chat apporte sa proie morte : c'est pour que tu te nourrisses avec. Ensuite il te l'apporte vivante pour t'apprendre à chasser.

                Comme si t'étais un de ses petits. Les chats c'est rien que des branleurs ;)

                Skoi un(e) picooz ?

                Moi je ne laisse pas mes deux chattes s'attaquer aux frelons et aux guêpes, j'ai trop peur qu'elles se fassent piquer. Je m'en occupe moi même, tatane à la main :/

                • [^] # Re: Nom de code

                  Posté par . Évalué à  2 .

                  Skoi un(e) picooz ?

                  Abeilles, guêpes et autres saloperies qui piquent ?

                  • [^] # Re: Nom de code

                    Posté par . Évalué à  6 .

                    C'est un petit hélicoptère télécommandé d'appartement

  • # Sockets Unix

    Posté par (page perso) . Évalué à  5 .

    À propos des optimisations sur les sockets Unix. Ça arrive souvent d'avoir 200k sockets ouvertes ou ce sont des cas particuliers ? Personnellement, je suis loin du compte :

    $ sudo wc -l /proc/net/unix
    [sudo] password for xavier: 
    901 /proc/net/unix
    
    

    « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

    • [^] # Re: Sockets Unix

      Posté par (page perso) . Évalué à  5 .

      C'est peut-être plus le cas sur des serveurs ou sur des machines multi-utilisateurs.

    • [^] # Re: Sockets Unix

      Posté par . Évalué à  5 .

      Quand tu vois qu'ils font aussi des optimisations pour 4096 processeurs, tu te dis qu'il y a des p…. d'ordinateurs qui font tourner Linux..

      • [^] # Re: Sockets Unix

        Posté par (page perso) . Évalué à  2 .

        Gamme UltraViolet chez SGI si mes souvenirs sont bons…

      • [^] # Re: Sockets Unix

        Posté par (page perso) . Évalué à  2 .

        Justement, ma question c'est de savoir si ça concerne une toute partie des utilisateurs ou si c'est un cas assez fréquent.

        « Moi, lorsque je n’ai rien à dire, je veux qu’on le sache. » Raymond Devos

        • [^] # Re: Sockets Unix

          Posté par (page perso) . Évalué à  1 . Dernière modification : le 18/10/12 à 12:40

          Sur des serveurs à forte charge, ont tourne plutot 10x moins de socket ouvert (je parle de gros e-commerce du web français).

          C'est plus sur les desktops que c'est la fête, avec 1000 socket ouvert en moyenne pour les machins de type KDE. Mais toutes les optimisations sont bonnes à prendre.

          Par exemple si les intel atoms 500 coeurs sorte l'année prochaines, le support de beaucoup de coeurs est bon à prendre.

          Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

  • # Distribution et numérotation debian. Questions de noob.

    Posté par . Évalué à  3 .

    Je suis surpris qu'autant de branches parallèles soient maintenues.

    Dans debian Wheezy (et Sid), c'est la version 3.2 qui est proposée. A ma connaissance, c'est la seule disponible pour cette distribution.

    Quelle est la raison à cela ? Ça serait trop de boulot d'en proposer d'autres ?

    Pourquoi ne pas passer à une version supérieure (je ne dis pas "plus récente" car la 3.2 a des changements récents aussi) ? Pour ne rien casser ? Ce serait pourtant une version stable aussi.

    En fait je ne comprends pas la numérotation debian.

    Le paquet linux-image-amd64 (3.2+45) depends on the latest Linux kernel and modules for use on PCs with AMD64 or Intel 64 processors, en l'occurrence actuellement, le paquet linux-image-3.2.0-3-amd64.

    J'imagine que ça correspond à la branche contenant la version stable 3.2.30 du noyau, mais est-ce que le 45 de 3.2+45, le 0 de 3.2.0-3-amd64 et le 30 de 3.2.30 sont homogènes ? Que faut-il comparer pour s'y retrouver ?

    Pourquoi pas des versions supérieures dans experimental, ou bien dans des paquets avec un autre nom ?

    • [^] # Re: Distribution et numérotation debian. Questions de noob.

      Posté par . Évalué à  4 .

      Quelle est la raison à cela ? Ça serait trop de boulot d'en proposer d'autres ?

      Oui, Debian «s'engage» à maintenir le kernel durant toute la durée de vie de la distribution (c'est à dire environ 3 ans en général), ceci même s'il n'y a plus de support de la part de l'équipe Linux.

      C'est par exemple le cas pour la Squeeze et son kernel 2.6.32, pourtant un LTS («Long-Term-Support»).
      D'ailleurs ce 2.6.32 avait été choisi plus ou moins en commun avec d'autres distributions pour mutualiser leur travail.
      Je suis donc assez surpris qu'ils aient choisi un 3.2* pour Wheezy, qui pour moi n'est pas un kernel LTS justement (contrairement aux 3.0* et 3.4*).

      Néanmoins, on a toujours possibilité d'utiliser ceux de Sid (quand elle n'est pas gelée) ou Experimental.

      • [^] # Re: Distribution et numérotation debian. Questions de noob.

        Posté par . Évalué à  2 .

        Néanmoins, on a toujours possibilité d'utiliser ceux de Sid (quand elle n'est pas gelée) ou Experimental.

        Effectivement, je n'avais pas vu celui d'Experimental, justement parce qu'il n'est pas considéré comme une autre version du même paquet, mais bien comme un paquet différent.

        Je crois que je peux l'installer sans problème de dépendance, donc sans même devoir faire du pinning ni rien, juste en téléchargeant le .deb tout seul. Au moins pour essayer. Si je le garde, il vaudrait mieux pinner pour avoir les mises à jour.

        Merci !

        • [^] # Re: Distribution et numérotation debian. Questions de noob.

          Posté par . Évalué à  2 .

          Comme je laisse entendre quelque chose d'un peu incorrect, je m'auto-réponds pour ajouter que le cas d'experimental est particulier. Même sans pinning, il est possible d'ajouter la ligne experimental dans sources.list et par défaut les paquets d'expérimental ne seront pas utilisés. Par opposition par exemple à sid. Si j'ajoute Sid sans déclarer de priorité (pinning), ça va m'installer la version Sid de tous mes paquets. Pour installer un paquet d'experimental, il faut en plus forcer l'opération avec l'option -t.

          apt-get -t experimental install linux-image-3.5-trunk-amd64
          
          

          C'est expliqué ici et ici.

  • # A quand l'integration du support de LLVM dans la branche principale?

    Posté par (page perso) . Évalué à  1 .

    A quand l'integration du support de LLVM dans la branche principale? Histoire de faire des testes, tester l'optimisation lors de l'édition des liens, booster le temps de compilation, ou juste introduire de la souplesse et de la flexibilité.

    Mon projet libre: http://ultracopier-fr.first-world.info/, mon jeu libre: http://catchchallenger.first-world.info/

Suivre le flux des commentaires

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