La sortie de la version stable 4.6 du noyau Linux a été annoncé le dimanche 15 mai 2016 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).
Sommaire
- En bref
- Annonces des versions candidates par Linus Torvalds
- Les nouveautés
- Intégration dans les distributions
- Le bilan en chiffres
- Appel à volontaires
En bref
Le noyau Linux 4.6 est dans l’ensemble une grosse version, qui comporte beaucoup plus de commits que d’habitude. Cette version apporte le nouveau système de fichiers distribué OrangeFS, la gestion de l’USB 3.1, des améliorations de l’efficacité du tueur de processus qui débordent sur la mémoire, ainsi que la gestion des clefs de protection de la mémoire pour les processeurs Intel, la connexion multiplexeur et le chiffrement IEEE 802.1AE de l’adresse MAC.
De plus, le noyau gère la version cinq du protocole B.A.T.M.A.N. (Better Approach To Mobile Adhoc Networking), le vérificateur en ligne de nœuds d’index pour le système de fichiers OCFS2, le dma-buf, la gestion des espaces de noms des cgroups et la gestion de la couche pNFS SCSI.
Annonces des versions candidates par Linus Torvalds
RC-1
La version RC-1 est sortie le samedi 26 mars 2016 :
Alors, je ferme la fenêtre d’intégration un jour en avance, d’une part parce que j’ai des voyages à venir, mais d’autre part parce que ce fut une des plus grosses fenêtres d’intégration depuis un moment et si quelqu’un planifiait de glisser une modification à la dernière minute, je ne veux vraiment pas en entendre parler.
De manière globale, en dépit de la durée de la fenêtre d’intégration, ce fut principalement sans douleur. Il y a eu assez peu de conflits et la branche ARM, qui en compte traditionnellement le plus, fut l’une des plus faciles. Bon travail.
Bien sûr, pour compenser ça, nous avons eu quelques problèmes inhabituels de système de fichiers, avec les demandes d’intégration de F2FS et Ceph nécessitant un rappel à l’ordre pour avoir désorganisé leur branche, dans les deux cas pour essayer de les rendre plus simples pour l’intégration, mais dans les deux cas, je souhaite vraiment, vraiment, que les gens ne se préoccupent que de leur propre code et non qu’ils fassent des changements pour s’adapter à ce qui se passe en dehors de leur branche.
Mais il s’agissait principalement de problèmes de maintenance de git et non du code en lui‐même… Et, tant qu’on parle de la partie système de fichiers, il est à noter que nous avons aussi un nouveau système de fichiers cette fois‐ci : OrangeFS. En fait, il était en attente depuis longtemps, la première demande d’intégration datant de fin août, mais il a été longtemps mis en attente à cause du travail d’Al qui a, je pense, rendu tout le monde plus heureux. La demande d’intégration en elle‐même est arrivée assez tard dans la fenêtre d’intégration, mais je suis content qu’elle soit enfin intégrée — les développeurs d’OrangeFS ont été très réactifs aux problèmes qui ont été soumis.
Mais comme d’habitude, la majeure partie des changements — de loin — est juste l’ensemble des diverses mises à jour de pilotes. Donc, malgré le travail sur le système de fichiers, les pilotes représentent environ ⅔ des changements. Il y en a partout : pilotes staging, réseau, DRM, RDMA, USB, média, son — ce que vous voulez.
En dehors des pilotes, le plus gros des changements est, comme d’habitude, les mises à jour d’architecture : la branche ARM étant une grosse partie, mais il y a d’autres mises à jour ARM (et AMR64), combinées avec x86, PowerPC, S/390, Xtensa, et quelques m68k.
Le reste est la partie générale du réseau, mises à jour des systèmes de fichiers (en plus des trucs déjà mentionnés sur OrangeFS, F2FS et Ceph, il y a aussi des mises à jour sur XFS, Btrfs, OCFS2, ext4 et la partie générique VFS). Et le travail sur la base du noyau, ainsi que des mises à jour de documentation et d’outillage.
Donc, pas mal de travail partout. Le journal abrégé étant beaucoup trop gros à poster, j’ajoute simplement mon habituel « journal de fusion » qui montre de qui j’ai récupéré les modifications, avec une très courte description. Comme d’habitude, l’intégralité des crédits se trouve dans l’arbre git.
Espérons qu’une fenêtre d’intégration raisonnablement indolore se transforme en une période d’accalmie encore plus indolore, bien que ce soit une assez grosse sortie.
S’il vous plaît ?
Linus
RC-2
La version RC-2 est sortie le dimanche 3 avril 2016 :
Vous connaissez tous le refrain maintenant — une autre semaine, une autre RC. Je dirais que les choses ont l’air normales sur ce point : ce n’est pas une grosse RC-2, mais cela a été vrai récemment (les RC-3 ont tendance à être un peu plus grosses — probablement juste parce que ça prend du temps pour que les gens se rendent compte des problèmes).
Les statistiques du correctif ont l’air plutôt normales aussi : environ la moitié sont des pilotes, environ le quart sont des corrections d’architectures, et le reste est principalement du réseau et des mises à jour de documentation. Mais il y a aussi quelques corrections au cœur du noyau, de la gestion de la mémoire, des systèmes de fichiers.
Le journal abrégé est joint et donne une bonne idée des types de changements que nous avons.
Allez‐y, testez, rien n’a l’air particulièrement effrayant ici.
Linus
RC-3
La version RC-3 est sortie le dimanche 10 avril 2016 :
Le fait que la RC-3 est plus grosse que la RC-2 devient une tendance (mon explication est qu’il se passe un temps avant que les gens trouvent des problèmes, en plus de la pause qu’ils prennent après la fenêtre d’intégration), donc ce point n’est pas surprenant.
Ce qui est surprenant, toutefois, est que la moitié du gros des correctifs de la RC-3 concerne du code de système de fichiers. Je ne me souviens pas d’une situation similaire, et cela m’a surpris — J’ai dû aller en chercher la raison. Il s’avère que bien que nous ayons effectivement des changements sur plusieurs systèmes (Btrfs, ext4, OrangeFS, F2FS), la grosse raison était simplement le remplacement de la macro
PAGE_CACHE_SIZEparPAGE_SIZEpartout. Et le code faisait grand usage de ce nommage reliquaire.De toute façon, une fois cette petite bizarrerie expliquée, les statistiques ont l’air assez normales, le reste étant essentiellement des pilotes. Le plus gros correctif est la résurrection du pilote staging
olpc_dcon, qui n’était pas si obsolète que ça, après tout. On a raté un truc là, puisque cette résurrection a raté Pâques d’une semaine. On fera mieux dans le domaine des dates rigolotes la prochaine fois, promis.Il y a également l’habituel saupoudrage de correctifs d’architectures, mais c’est assez léger.
Dans l’ensemble, je trouve qu’on est bon. Il est assez tôt dans les RC, mais tout semble nickel. Allez‐y, testez.
Linus
RC-4
La version RC-4 est sortie le dimanche 17 avril 2016 :
Ce fut une semaine assez calme, et la RC-4 n’est pas si grosse que ça. Il n’y a rien de particulièrement effrayant.
Des changements dans tout l’arbre, les pilotes (40 %) et des correctifs d’architectures (30 %) représentant le gros de la chose. Le reste est saupoudré autour, et c’est tout petit. En fait, les correctifs « VM » représentent plus de 5 % du correctif, mais c’est uniquement parce qu’on s’est débarrassé de la bidouille conversion-time, d’où quelques conventions d’appel différentes pour
get_user_pages().Donc, rien de particulièrement intéressant. C’est comme ça que j’aime les RC, espérons que ça reste ainsi.
Le journal abrégé est joint à l’attention de ceux qui ont du mal à trouver le sommeil.
Linus
RC-5
La version RC-5 est sortie le dimanche 24 avril 2016 :
Les choses continuent à être tout à fait calmes : la RC-5 est plus grosse que la RC-4, mais la RC-4 était vraiment petite.
Et, alors que nous sommes revenus cette fois à un nombre normal de changements pendant la fenêtre de sortie, les types de bogues trouvés restent très ordinaires : il n’y a absolument rien d’effrayant ici. Si l’on continue sur cette voie, ce pourrait être une de ces rares sorties qui n’ont pas besoin de six RC. Du moins, ça en a l’air pour le moment ; même si pour être honnête, je suspecte que, quand bien même les choses continuent de se calmer ainsi, je ferai une RC-7 normale, simplement parce qu’il n’y pas d’urgence, ni de raison de ne pas le faire.
Un comportement qui est très clair, c’est que les demandes d’intégration sont envoyées en fin de semaine. Plus de la moitié de toutes les intégrations ont été faites vendredi et particulièrement samedi. Je ne me plains pas, je pense que c’est juste un signe qu’il n’y avait rien de particulièrement urgent cette semaine, et donc les gens envoient leurs demandes d’intégration en fin de semaine de travail et/ou savent juste que la RC arrive.
De toute façon, le gros des changements vient des pilotes, comme d’habitude (à environ 60 % — les pilotes Ethernet ressortent des statistiques de diff, mais c’est plutôt disséminé), avec le réseau et l’outillage pour la majeure partie du reste. Il y a quelques autres petits changements et vous pouvez avoir un aperçu des détails en survolant le journal abrégé en annexe.
Allez‐y, testez. Ça a l’air robuste.
Linus
RC-6
La version RC-6 est sortie le dimanche 1er mai 2016 :
Les choses continuent d’être plutôt calmes, même si je suis presque sûr de faire une RC-7 dans cette série.
Il n’y a rien de particulièrement effrayant ici — il y a un correctif pour le problème récurrent des interfaces infiniBand, mais comme cela concerne du matériel spécifique, ça ne risque pas de toucher beaucoup de gens, et le contournement du bogue était assez simple. La majeure partie du reste est juste le bruit de fond normal. Les pilotes (son, pilotes graphiques et Ethernet principalement), les architectures (ARM, S/390, x86), le réseau en prenant la plus grande part.
Le journal abrégé est joint pour votre édification.
Linus
RC-7
La version RC-7 est sortie le dimanche 8 mai 2016 :
Donc, voici la RC-7 parce que, bien que les choses aient été vraiment calmes pendant un bon moment, ça n’a pas été calme au point que je décide que ça ne vaille pas le coup de faire la traditionnelle dernière RC. Mais c’est ainsi, à moins que quelque chose de surprenant n’arrive.
Il n’y a rien de particulièrement étrange ici et le journal abrégé joint est suffisamment petit pour le survoler et avoir un aperçu des détails. C’est principalement des petites corrections de pilotes et d’encore plus petites mises à jour d’architectures. Ajoutez du réseau, quelques correctifs du cœur du système de fichiers et du noyau et c’est à peu près tout.
Rien de particulièrement effrayant et, plus de gens la testeront, plus nous pourrons être confiants que la 4.6 finale sera très bonne. Donc, s’il vous plaît, prenez un moment pour l’essayer,
Linus
Version finale
La version finale est sortie le dimanche 15 mai 2016 :
C’est une bonne chose de ne pas avoir clos le cycle des RC trop rapidement, puisque la semaine dernière s’est terminée avec un peu plus de correctifs que prévu, mais rien ne semble bizarre ou anormal. Donc, la version 4.6 est sortie comme prévu et ça signifie évidemment que je vais ouvrir la fenêtre d’intégration pour la 4.7 dès demain.
Depuis la RC-7, il y a eu un peu de bruit un peu partout, les corrections de pilotes en représentant la plus grande partie, mais il y a du bruit plus léger un peu partout (outils de perf, réseau, systèmes de fichiers, documentation, quelques petits correctifs d’architectures…).
Le journal abrégé joint vous donnera un aperçu de ce qui s’est passé durant la semaine écoulée. Le noyau 4.6 était dans l’ensemble assez gros — plus de correctifs que j’en ai eu depuis un moment. Mais, tout a semblé plutôt calme malgré tout.
Linus
Les nouveautés
Architecture
Ordonnanceur
L’introduction des files simples permet une autre gestion des processus et diminue la mémoire tout en augmentant les performances.
Pour les systèmes NUMA (multi‐socket), une meilleure répartition des processus permet d’avoir plus de bande passante mémoire et donc de meilleures performances.
L’option NOHZ, qui permet d’économiser l’énergie en ne générant pas d’interruptions quand le processeur est à vide, est aussi plus performante.
EFI
Diverses améliorations de l’EFI ont été faites, particulièrement en isolant le contexte de l’EFI du reste du noyau, cela permet une meilleure sécurité. Le noyau peut désormais fonctionner avec un micrologiciel UEFI et les interruptions.
Même si des améliorations sont à noter dans la partie x86, les architectures ARM 64 bits ne sont pas en reste.
USB 3.1
Gestion du protocole SuperSpeed Plus (SSP) pour l’USB 3.1 qui offre des vitesses de transfert pouvant aller jusqu’à 10 Gbit/s.
Générique
Plus de code assembleur a été porté en C, ce qui permet un code générique et réutilisable sur d’autres plates‐formes. Et cela permet aussi au compilateur de faire des optimisations spécifiques au processeur utilisé.
L’outil objtool a évolué pour trouver plus facilement les bogues dans le code assembleur du noyau.
Gestion d’énergie
AHCI
L’AHCI est une norme des contrôleurs SATA, une meilleure gestion de l’énergie, surtout via la mise en suspension, permet de gagner en énergie.
FBC et PSR pour les cartes graphiques Intel
La compression du tampon de trames (Frame Buffer Compression — FBC) est maintenant activée par défaut, cela permet de transférer moins d’informations.
Le Panel Self Refresh (PSR) est aussi activé, cela permet de réduire la consommation en ne renouvelant pas l’image affichée si celle‐ci ne bouge pas. Le gain peut aller de 29 % à 85 %.
CPUFreq et PState
Tout d’abord, la manière dont se déclenchent les mises à jour de la fréquence processeur est maintenant différente. Au lieu d’avoir à mettre en place et gérer une horloge programmée pour chaque processeur du système, pour évaluer et éventuellement modifier périodiquement sa fréquence, les régulateurs de cpufreq demandent l’aide de l’ordonnanceur régulièrement (essentiellement lors des mises à jour d’utilisation). Les « anciens » régulateurs on demand et conservative, font toujours tout leur travail dans le contexte du processus (bien que cela soit déclenché par l’ordonnanceur maintenant), mais intel_pstate fait tout lors du rappel invoqué par l’ordonnanceur sans avoir besoin de tout traitement asynchrone supplémentaire.
Bien sûr, ça élimine les surcharges liées à la gestion de tous ces minuteurs, mais ça permet aussi de simplifier un peu le code du régulateur de cpufreq. En outre, le code commun et les structures de données utilisés par les régulateurs on demand et conservative sont nettoyés et rendus plus simples. Et certains problèmes assez ennuyeux et qui perduraient sont traités. En particulier, la gestion des attributs du régulateur sysfs est modifiée et le verrouillage associé est plus finement granularisé ce qui permet à certains problèmes d’accès simultanés d’être évités (notamment les blocages avec le code du cœur de cpufreq).
En principe, le nouveau mécanisme de déclenchement des changements de fréquence permet de passer des informations d’utilisation de l’ordonnanceur à cpufreq. Bien que le code actuel ne fasse pas usage de celui‐ci, il y a en travaux un nouveau régulateur de cpufreq qui prendra des décisions fondées sur les données d’utilisation de l’ordonnanceur. Cela devrait permettre à l’ordonnanceur et cpufreq de travailler ensemble plus étroitement à long terme.
ARM
Systèmes monopuces gérés
Des dizaines de nouveaux systèmes monopuces (SoC) sont gérés :
Axis ARTPEC-6 (artpec6), TI Keystone K2G (keystone-k2g), Mediatek MT7623 (mt7623), Allwinner A83T (a83t), NXP i.MX6QP (imx6qp), ST Microelectronics STM32F469 (stm32f469), Annapurna Labs Alpine (alpine-v2), Marvell Armada 3700 (armada-37xx), Marvell Armada 7000/8000 (armada-7xxx/8xxx), Amlogic S905 (meson-gxbb), Qualcomm SnapDragon 820 (msm8996), Socionext UniPhier (uniphier-ph1), ARM Juno Development Platform (juno-r2), Allwinner A64 et Broadcom Vulcan (vulcan).
Et beaucoup d’améliorations du côté de la prise en charge d’ARM 64 bits.
Développement
Pilotes graphique libres
Direct Rendering Manager
La principale nouveauté pour les utilisateurs de cette version du code commun des pilotes graphiques DRM est la possibilité de sélectionner à chaud le processeur graphique sur lequel exécuter une application pour les MacBook Pro pré‐Retina. La gestion des MacBook Pro Retina est en cours de développement et arrivera dans le futur.
Une autre nouveauté importante est l’ajout d’une interface permettant de tester la conformité des pilotes DisplayPort. La gestion d’un nouveau panneau d’affichage (ARM HDLCD) fait également son apparition.
Pour plus d’informations, vous pouvez consulter la demande d’intégration faite par Dave Airlie.
AMD (pilotes radeon et amdgpu)
Le changement inclut des améliorations sur le coprocesseur audio, l’optimisation des contrôles d’entrées-sorties ioctl liés aux nuanceurs de calcul (compute shaders), l’optimisation de l’ordonnanceur, l’optimisation du processeur graphique virtuel (GPUVM), la gestion préliminaire de la réinitialisation du processeur graphique, une nouvelle interface PowerPlay (gestion d’énergie) et la correction de la virtualisation.
Pour les possesseurs de processeurs graphiques AMD un peu anciens, aucune nouveauté du côté du pilote Radeon.
Pour plus d’informations, vous pouvez consulter la demande d’intégration d’AMD.
Intel (pilote i915)
La nouveauté principale pour le pilote Intel est la prise en charge du rafraîchissement automatique du panneau d’affichage, ainsi que la compression du tampon de trame (framebuffer) dans la majorité des plates‐formes. Elle aurait pris plus d’un an à deux ingénieurs, mais cela permet désormais d’économiser beaucoup d’énergie lorsque l’utilisateur utilise faiblement la machine, comme c’est le cas lors du visionnage de pages Web. Toujours concernant l’efficacité énergétique, les processeurs Skylake se rapprochent d’une gestion dynamique de l’horloge à destination des contrôleurs vidéo (CRTC).
Du côté de la gestion atomique du mode graphique, le travail continue avec la conversion du code de détection des moniteurs et de celui des filigranes des tampons des contrôleurs vidéo (CRTC).
Pour plus d’informations, vous pouvez consulter l’article de blog de Daniel Vetter, mainteneur du pilote i915.
Nouveau
Très bonne nouvelle pour le pilote Nouveau, NVIDIA a enfin rendu public à la fois les micrologiciels nécessaires à la prise en charge de la 3D pour la deuxième génération de processeurs graphiques Maxwell (sortie le 1er juin 2015) ! Ces micrologiciels étant signés par NVIDIA, il était impossible pour les développeurs de Nouveau de produire leurs propres micrologiciels, comme ils le faisaient pour les générations précédentes.
Il aura donc fallu plus de six mois pour que NVIDIA rende ce code public, ce qui a ralenti les efforts de développement sur les processeurs Maxwell. Cependant, quelques jours à peine après la gestion expérimentale dans le noyau, la gestion des nouveaux processeurs graphiques est apparue dans Mesa 3D et est disponible dans Mesa 3D 11.2. Cependant, cette gestion n’est pas au niveau des processeurs Kepler qui gèrent OpenGL 4.3 et OpenGL ES 3.1. Maxwell est, quant à lui, limité à OpenGL 3.3 à cause de l’absence de gestion des nuanceurs (shaders) de tessellation et de la gestion du chargement et de l’enregistrement direct d’image Image Load/Store. Cette gestion est cependant en cours de développement, ce qui devrait permettre à tous les processeurs graphiques qui le gèrent d’exposer OpenGL 4.5 et OpenGL ES 3.2 avant la fin de l’année !
Pour finir, les possesseurs de cartes graphiques de milieu et de haut de gamme peuvent désormais suivre la consommation énergétique de leur processeur graphique, chose qui n’est pas possible avec les pilotes officiels de NVIDIA.
Raspberry Pi (pilote vc4)
De nombreuses améliorations de la couche 3D du Raspberry Pi ont été faites, tant du côté DRM (noyau) que VC4 Gallium3D (espace utilisateur).
Grâce à l’amélioration du pipelining et du rendu, certains tests gagnent jusqu’à 20 à 30 %, même si dans les jeux, cela est moins spectaculaire. Cela est fait via l’utilisation de fils d’exécution (threads) qui permettent de limiter les passages à vide.
Pour plus d’informations, vous pouvez consulter la demande d’intégration.
Autres
Le pilote Exynos (Samsung) reçoit dans cette version la gestion des systèmes monopuces 5420 et 5422. [demande d’intégration]
Le pilote msm (Qualcomm) gère dorénavant l’Adreno 430, ainsi que le HDMI pour les SnapDragon 820.
Réseau
Pilotes
Divers ajouts et améliorations sur les puces Realtek.
Coupe‐feu
Ajout de nouveau type BFP, le filtre BFP est par exemple utilisé dans le coupe‐feu pour l’optimiser.
Autre
Traitement par fil d’exécution des entrées TCP et UDP, un multiplexeur pour les flux TCP, la gestion du 802.1AE MACsec, divers travaux de décharge de la couche réseau (par exemple, le calcul de la somme de contrôle en local).
Sécurité
MPK-PKeys
Les clefs de protection mémoire (Memory Protection Keys) sont des mécanismes de protection de la mémoire. Elles associent une page mémoire à une clef, et lors d’un accès à cette page mémoire, la clef est vérifiée afin de s’assurer que seul le programme autorisé y accède. Ce mécanisme sera ajouté lors d’une prochaine version des microprocesseurs Intel.
32 bits
Pour la sécurité des programmes 32 bits, la distribution aléatoire de l’espace d’adressage est activée, cela permet de se défendre d’un attaquant qui essayerait d’injecter des données à une adresse déterminée à l’avance.
Systèmes de fichiers
ext4
Il y a beaucoup de corrections, d’optimisations lors du changement de position dans un fichier, une meilleure mise à l’échelle des attributs étendus (xattr) et diverses corrections de bogues.
F2FS
Il y a des changements pour la partie chiffrement, des améliorations des entrées‐sorties asynchrones (AIO — Asynchronous I/O), des optimisations du changement de position dans un fichier.
XFS
Les nouveautés sont une meilleure gestion des erreurs pour les échecs d’entrées‐sorties directes (O_DIRECT), une nouvelle interface pour les quotas, des corrections de bogues, une réduction des informations dupliquées entre XFS et VFS (couche d’abstraction de système de fichiers du noyau), nettoyage des drapeaux du tampon.
OrangeFS
OrangeFS est désormais pris en charge par le noyau Linux. Il est principalement utilisé dans les grappes de serveurs présentes dans les universités, les centres de recherche et les entreprises.
C’est, au même titre que CeFS ou GlusterFS, un système de fichiers décentralisé réparti. Il a été en partie élaboré lors d’études de la NASA pour les schémas d’entrées‐sorties parallèles.
Il gère la répartition entre plusieurs serveurs, les accès simultanés de plusieurs clients, et garde les données et méta‐données via les systèmes de fichiers locaux.
Virtualisation
Espaces de nommage pour les cgroups
Ce petit code de seulement 600 lignes était en gestation depuis deux ans, il est utilisé pour faire le lien entre les cgroups (pour gérer un bloc de processus) et l’espace de nommage (isolation et vue unique d’un groupe de processus). Ce correctif permet de virtualiser les cgroups pour ne pas exposer d’informations globales et critiques dans un espace de nommage et permet d’améliorer la virtualisation de LXC, Docker et VServer.
Virtio
L’interface Virtio bénéficie de plusieurs améliorations : entre autres, virtio_net. Ce correctif permet à l’utilisateur d’obtenir et modifier la vitesse et le duplex du dispositif réseau via ethtool. Avoir cette fonctionnalité est très utile pour simuler des environnements différents et c’est parfois nécessaire quand les paramètres appropriés en vitesse et duplex sont requis.
Autres
Diverses améliorations pour Xen et KVM.
Intégration dans les distributions
Le noyau Linux 4.6 :
- est intégré dans les distributions Arch Linux et SparkyLinux ;
- sera intégré dans Fedora 24 après sa sortie prévue pour mi‐juin 2016.
Le bilan en chiffres
Cette version du noyau 4.6 a donné lieu à la participation de 1 661 développeurs, ce qui est un nouveau record, en battant le nombre des 1 625 contributeurs de la version 4.3. Parmi eux, 283 de ces développeurs ont fait leur premier commit au noyau au cours de ce cycle de développement.
Les développeurs les plus actifs en nombre de modifications sont Arnd Bergmann (204), Chaehyun Lim (197) et Oleg Drokin (165). En nombre de lignes de code, Faisal Latif (28 327), Dennis Dalessandro (16 034) et Mike Marshall (15 434) ont été les plus productifs.
Arnd Bergmann, développeur de longue date du noyau, est en tête de liste, principalement pour son travail en cours pour l’élimination des avertissements de compilation sur ARM.
Faisal Latif est le premier contributeur en nombre de lignes pour l’ajout du pilote infiniBand i40iw.
Parmi les entreprises les plus contributrices à ce noyau, c’est incontestablement Intel qui l’emporte loin devant Red Hat, Linaro et IBM. À noter, un nouveau venu parmi ces noms connus et habitués dans ce classement : Omnibond Systems, la société derrière OrangeFS.
Plus de chiffres sur ces contributions sur LWN.net.
Appel à volontaires
Cette dépêche est rédigée par plusieurs contributeurs dont voici la répartition :
| Mainteneur | Contributeur(s) | |
|---|---|---|
| La phase de test | Aucun | goernil |
| Arch | Herman BRULE (alpha_one_x86) | |
| Développeurs | ||
| Pilotes graphiques libres | Martin Peres | |
| Réseau | Aucun | Herman BRULE |
| Systèmes de fichiers | Aucun | Herman BRULE (alpha_one_x86) |
| Sécurité | ||
| Virtualisation | Xavier Claude | |
| Édition générale | Aucun | Moul, eggman, Yassin Philip, jcr83 |
Un peu de vocabulaire :
- le mainteneur d’une section de la dépêche est responsable de l’organisation et du contenu de sa partie, il s’engage également à l’être dans le temps jusqu’à ce qu’il accepte de se faire remplacer ;
- un contributeur est une personne qui a participé à la rédaction d’une partie d’une section de la dépêche, sans aucune forme d’engagement pour le futur.
Malgré cette équipe importante, beaucoup de modifications n’ont pas pu être expliquées par manque de temps et de volontaires.
Nous sommes particulièrement à la recherche de mainteneurs pour les sections Systèmes de fichiers et Réseau, les précédents n’ayant pas donné de signes de vie pendant la rédaction des dernières dépêches.
Si vous aimez ces dépêches et suivez tout ou partie de l’évolution technique du noyau, veuillez contribuer dans votre domaine d’expertise. C’est un travail important et très gratifiant qui permet aussi de s’améliorer. Il n’est pas nécessaire d’écrire du texte pour aider, simplement lister les commits intéressants dans une section aide déjà les rédacteurs à ne pas passer à côté des nouveautés. Essayons d’augmenter la couverture sur les modifications du noyau !
Aller plus loin
- Dépêches des noyaux précédents (204 clics)
- Site officiel du noyau Linux (176 clics)
- La liste des nouveautés sur Kernelnewbies.org (194 clics)
- Liste des nouveautés 1/2 sur lwn.net (103 clics)
- Liste des nouveautés 2/2 sur lwn.net (77 clics)
# Better Approach To Mobile Adhoc Networking
Posté par Firwen (site web personnel) . Évalué à 7. Dernière modification le 06 juin 2016 à 19:24.
Sincèrement, je doute qu'on trouve un meilleur nom de protocole que B.A.T.M.A.N un jour. J'ai un profond respect pour l'auteur originel qui a reussi à pondre un accronyme pareil.
https://www.youtube.com/watch?v=OpWVV8wuM1A
Rien qu'a la lecture du changelog, j'ai déjà le generique en tête.
( Merci pour la dépêche, c'est vraiment un excellent travail )
[^] # Re: Better Approach To Mobile Adhoc Networking
Posté par louiz’ (site web personnel) . Évalué à 2. Dernière modification le 06 juin 2016 à 23:40.
C’est ce générique qui est visé, quand les gens font « na na na na na BATMAN » ?
Si non, lequel est-ce ?
Edit : Ah oui, ben je me réponds à moi-même, tout à la fin on l’entend.
J’aurais appris quelque chose du coup, merci.
[^] # Re: Better Approach To Mobile Adhoc Networking
Posté par KiKouN . Évalué à 2.
Déconnez pas, ça ne doit pas être facile tout les jours d'être sérieux sur leur mailing list ou leur irc.
[^] # Re: Better Approach To Mobile Adhoc Networking
Posté par N-Mi . Évalué à 4.
Il y a aussi A.L.F.R.E.D : Almighty Lightweight Fact Remote Exchange Daemon ( https://www.open-mesh.org/projects/alfred/wiki )
Et encore RO.B.IN : ROuting Batman INside ( http://robin.forumup.it/ , ça a l'air abandonné)
[^] # Re: Better Approach To Mobile Adhoc Networking
Posté par GG (site web personnel) . Évalué à 2.
Il y a aussi BABEL https://fr.wikipedia.org/wiki/Babel_%28protocole%29
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Better Approach To Mobile Adhoc Networking
Posté par KiKouN . Évalué à 2.
Par contre, Babel, c'est vraiment mal vu comme nom de protocole. Babel corresponds plus à des grosse bibliothèques de mot, de traduction ou en relation avec le langage humain. Rien à voir avec le langage machine.
[^] # Re: Better Approach To Mobile Adhoc Networking
Posté par GG (site web personnel) . Évalué à 2.
Babel et Batman sont deux protocoles qui mettent en place un réseaux maillé automatiques.
On pourrait dire qu'ils sont concurrents, mais en réalité selon l'état, l'étendue et la qualité du réseau, l'un s'en sortira mieux que l'autre.
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
# Merci
Posté par Nibel . Évalué à 7.
Merci pour cette dépêche, toujours au top.
Je suis ravis de l'avancée du pilote Nouveau, même si il y a encore beaucoup de travail à faire, la libération des firmwares 3D de la part de Nvidia fait grand bien.
Beau travail pour les améliorations sur les perf' du Pi.
Et un nouveau FS, on crache pas dans la soupe même si je n'en aurai pas l'utilité pour l'instant.
Gros travail sur ce noyau.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Merci
Posté par Anonyme . Évalué à 1.
Waip, il reste effectivement du boulot. J’ai une nVidia série 9xx et il n’y a qu’une seule sortie reconnue sur les multiples disponibles. Pour l’instant je reste donc avec le pilote propriétaire. À voir pour les prochaines releases.
[^] # Re: Merci
Posté par eingousef . Évalué à 9.
publication
*splash!*
[^] # Re: Merci
Posté par Nibel . Évalué à 2.
Merci pour la correction :).
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Merci
Posté par Pazns . Évalué à 5.
C'est vrai, ça va, si Nvidia continue d'aider à ce rythme, on peut espérer un support de la toute récente fournée Pascal pour 2050 ! :D
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 07 juin 2016 à 02:12.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Merci
Posté par reynum (site web personnel) . Évalué à 4.
Je suis fâché avec Nvidia depuis que j'ai un portable avec Optimus mais sur mon Desktop où il n'y a qu'une seule carte je dois avouer (sans torture) que le driver proprio fonctionne plutôt bien.
kentoc'h mervel eget bezan saotred
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Merci
Posté par reynum (site web personnel) . Évalué à 8.
Il y a plus de 12 ans j'avais déjà un PC sous Linux avec une carte Nvidia car à l'époque il n'y avait que ça qui fonctionnait en accélération 3D, l'écran était à tube, la carte son en pci et tout fonctionnait super bien (et fonctionne encore mais plus chez moi).
Alors à moins d'avoir du matos encore plus vieux et noname je ne vois pas pourquoi ça ne marcherais pas, sauf peut être un bug assez fréquent d'ICC (Interface Chaise Clavier).
kentoc'h mervel eget bezan saotred
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10. Dernière modification le 07 juin 2016 à 22:24.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Merci
Posté par BAud (site web personnel) . Évalué à 5.
ah tiens, j'ai le même (non allumé depuis ~2 ans…). Oui, le souci de résolution est dû au fait que l'EDID n'est pas correctement fourni par l'écran… en spécifiant cekivabien dans le xorg.conf et en retrouvant comment le faire prendre en compte, ya moyen d'avoir la résolution correcte iirc, mais oui, faut un peu bidouiller la conf'. Bon, j'avais l'option "hub usb" sur cet écran, qui n'a jamais bien fonctionné du fait de l'état déplorable de la pile USB dans le noyau Linux… (ça a pu évoluer depuis les kernels 2.6.x mais bon).
Essaie tout de même avec une Mageia (en live cd par exemple), le XFdrake disponible dans le centre de contrôle de Mageia fera peut-être un miracle : http://doc.mageia.org/mcc/5/fr/content/XFdrake.html
[^] # Re: Merci
Posté par Pazns . Évalué à 1.
Il faudra voir si Wayland apportera une solution sur ce point, j'imagine.
Ça donnerait un truc du genre :
Xfce <-> XWayland <-> Wayland <--> Optimus ?
[^] # Re: Merci
Posté par Nibel . Évalué à 5.
Avec Optimus, les deux seuls problèmes que je constate avec le pilote proprio encore aujourd'hui :
- Pas de switch dynamique de GPU
- Problème de Vsync sur le GPU Nvidia
La résolution du Vsync avance petit à petit (le travail du côté de Xorg a bien avancé à en juger les derniers commits : https://cgit.freedesktop.org/xorg/xserver/log/ mais toujours rien chez Nvidia).
Concernant le switch dynamique, j'utilise un petit script qui remplace mes pilotes, mon xorg.conf et reboot sur le GPU demandé (ce qui prend moins de 5s pour retrouver un environnement directement utilisable, vive les SSD \o/).
Mais c'est vrai que depuis le temps, on est en droit d'attendre un meilleur support de la part de Nvidia.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Merci
Posté par reynum (site web personnel) . Évalué à 7.
En fait pendant quelques temps ça a bien fonctionné et utiliser la commande 'optirun' ne me dérangeait pas, mais les problèmes sont arrivé quand ma carte a cessé d'être supportée par le driver mainline.
Il existe bien un driver pakagé le 'nvidia-legacy-340xx-driver' mais il s'intègre mal avec bumblebee il faut modifier certain fichiers de conf à la main et même avec ça pas moyen de le faire fonctionner.
J'ai demandé de l'aide sur debian-fr.org et sur le github de bumblebee mais rien de concluant.
En attendant j'arrive à faire quelques trucs avec nouveau ; mais bon je lag pas mal dans Torchlight II alors qu'il tournais très bien avec le driver nvidia.
Conclusion nvidia 'Fuck You' ;-)
kentoc'h mervel eget bezan saotred
[^] # Re: Merci
Posté par Archange . Évalué à 2.
Est-ce que tu peux essayer ce qui t’as été demandé sur GitHub du coup (glsanity) ? Ou alors réexpliquer ta situation là-bas si ton problème n’est plus le même ? Merci.
[^] # Re: Merci
Posté par reynum (site web personnel) . Évalué à 2.
j'arrive pas à compiler glsanity -_- faudrait que je m'y remette mais comme il n'y a pas de configure c'est dur de trouver les dépendances manquantes
kentoc'h mervel eget bezan saotred
[^] # Re: Merci
Posté par Archange . Évalué à 1.
Je ne me souviens pas avoir réussi non plus lorsque j’avais essayé, car il y a pas mal de subtilités. Mais il y a des binaires précompilés : https://github.com/amonakov/glsanity/releases/download/2/glsanity-bin.zip.
Je te propose qu’on continue plutôt sur GitHub, dans le fil dédié. ;)
[^] # Re: Merci
Posté par reynum (site web personnel) . Évalué à 2.
Yep avec plaisir !
kentoc'h mervel eget bezan saotred
[^] # Re: Merci
Posté par Nibel . Évalué à 1.
Je déconseille en général fortement l'utilisation de Bumblebee aux personnes qui recherchent des performances dans les jeux. Le soft n'est plus maintenu (pas de MAJ depuis 3 ans) et les performances sont réellement exécrables.
Optimus est géré nativement par le pilote proprio, moyennant les problèmes cités dans mon précédent messages mais avec comme avantage d'avoir des performances équivalentes à ce qu'on pourrait avoir sous Windows ;).
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Merci
Posté par reynum (site web personnel) . Évalué à 2.
OK mais si j'installe seulement le driver proprio et que je veux lancer un appli qui utilise opengl par exemple freecad j'ai :
ou alors
ou encore cheese qui me sort toute la backtrace et memory map :
Bref le driver proprio ne fonctionne pas correctement c'est pour ça que je m'étais tourné vers bumblebee qui lui a fonctionné pendant quelques années.
Mais si tu me dis que ce driver une fois débuggé peut switcher à chaud mes cartes vidéos alors je veux bien ton script et me passer de bumblebee :)
kentoc'h mervel eget bezan saotred
[^] # Re: Merci
Posté par Nibel . Évalué à 1.
Etrange, je vais suivre ton fil github pour éviter de polluer plus ici.
Attention cependant, j'ai bien précisé que le switch dynamique de GPU (donc à chaud) n'était pas encore implémenté et je ne sais pas s'il le sera un jour. Mon script se contente simplement d'installer soit le driver Intel, soit le driver Nvidia proprio, désinstalle l'autre, remplace le xorg.conf par celui correspondant puis reboot la machine. Sur ma configuration ça ne prend que quelques secondes donc c'est assez peu dérangeant, pour d'autres ça peu être bloquant j'en conviens.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Merci
Posté par Archange . Évalué à 1.
Ah, j’avais pas compris que tu redémarrais carrément ta machine (en plus d’installer/désinstaller les drivers). Tu t’embêtes beaucoup trop !
Il est possible d’avoir les deux drivers installés en même temps, et de redémarrer seulement le serveur d’affichage (=déconnexion puis reconnexion) pour basculer. Le paquet nvidia-prime sous Ubuntu permet de faire ça très simplement (avec un bouton pour basculer), je peux éventuellement écrire la doc pour d’autres OS ou créer un paquet ArchLinux (s’il n’existe pas déjà) si besoin.
Quand au switch dynamique, je pense qu’il est implémenté, mais ne peut pas être publié car comme je disais, il faut que les drivers soient compatibles avec la licence GPL (donc libres) pour pouvoir utiliser ce mode sous Linux. Je n’ai plus les détails techniques en tête (c’est vieux tout ça…), mais je peux retrouver si ça intéresse.
[^] # Re: Merci
Posté par Nibel . Évalué à 1.
J'ai toujours eu une couille sur mon redémarrage de X, je reste sur le prompt à chaque fois, c'est pour ça que j'ai choisi la solution reboot même si effectivement, c'est pas forcément ce qui se fait de mieux.
Il y avait un paquet nvidia-prime sur AUR4 mais il n'a jamais fonctionné. Il n'y est plus depuis le passage à AUR5. Je devrais pouvoir me faire un paquet aussi s'il n'y a rien d'extravagant.
Je ne connaissais pas cet aspect technique, ça m'intéresse en effet si tu as quelque chose sous la main mais ne t'embête pas à aller chercher autrement.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Merci
Posté par Archange . Évalué à 2.
Voilà, j’ai retrouvé ceci (tout en anglais, je ne suis pas sûr qu’il y ait des sources en français sur le sujet):
https://www.phoronix.com/scan.php?page=news_item&px=MTA0ODE
https://www.phoronix.com/scan.php?page=news_item&px=MTE3MzY
https://www.phoronix.com/scan.php?page=news_item&px=MTA1OTU
https://www.phoronix.com/scan.php?page=news_item&px=MTIwNDI
https://www.phoronix.com/scan.php?page=news_item&px=MTIwOTI
https://www.phoronix.com/scan.php?page=news_item&px=MTMwMjI
Il y a aussi plein de choses dans les liens mentionnés (surtout ceux qui redirigent vers des threads complets de ML), ainsi que dans les commentaires, mais t’en prends pour la fin de la semaine si tu veux lire tout ça !
Ce qu’il faut retenir, c’est que Nvidia a réussi à bidouiller un peu pour pouvoir réaliser leur mode de fonctionnement « inversé », mais que le mode normal leur reste inaccessible.
[^] # Re: Merci
Posté par Archange . Évalué à 1.
Ce que tu vois là, ce sont juste des problèmes d’install/de config.
On peut régler ça sur le fil GitHub, que ce soit pour faire fonctionner Bumblebee ou nvidia dans la configuration proposée par Nibel. ;)
[^] # Re: Merci
Posté par reynum (site web personnel) . Évalué à 2.
Ok ce soir j'étais un peu occupé mais du coup demain je vais essayer de m'y mettre.
juste pour savoir quoi poster sur github, quelles infos vous faut il pour corriger ce problème ?
kentoc'h mervel eget bezan saotred
[^] # Re: Merci
Posté par Archange . Évalué à 2.
Poste déjà la sortie de glsanity (lis les instructions qui vont avec), après on verra. ;)
[^] # Re: Merci
Posté par reynum (site web personnel) . Évalué à 2.
Fait, par contre c'est pas très verbeux
kentoc'h mervel eget bezan saotred
[^] # Re: Merci
Posté par Archange . Évalué à 6.
Bumblebee est maintenu (même s’il y a eu de gros blancs et peu d’activité générale), mais un bug critique côté gestion d’énergie (y compris côté nouveau/PRIME, donc noyau) retarde la sortie de la version 4.0. L’ETA est d’environ 1 mois ou 2. S’il n’y a pas eu de MàJ pendant longtemps, c’est que rien ne le nécessitait (ce n’est plus tout à fait vrai depuis quelques temps avec la multiplication des modules noyau côté nvidia, et quelques menus bugs qui se sont ajoutés avec le temps).
Par contre, niveau performances, c’est parfaitement vrai, et il n’est pas possible de faire beaucoup mieux (dans Bumblebee) car c’est inhérent au mode de fonctionnement. La solution s’appelle PRIME, sauf que nvidia ne le gère pas, pour des raisons légales comme je disais plus haut.
Il reste la possibilité de faire du Reverse PRIME, avec les bugs que tu mentionnes en effet, et une assez grosse lourdeur côté basculement de carte graphique (personnellement, je ne peux pas me permettre de redémarrer mon serveur X à tout bout de champ).
L’idéal serait que nouveau, le pilote libre qui gère tous ces modes, s’affranchisse de ses gros problèmes de performances (qui sont au-delà des limitations de Bumblebee…).
Donc non, Optimus n’est pas géré nativement par le pilote proprio, seulement un ersatz d’Optimus, à tel point que la techno pré-Optimus fonctionnait mieux de ce point de vue-là. :p
J’ai écrit une réponse ici sur le choix entre ces différents modes de fonctionnement (en anglais): https://askubuntu.com/a/775161/493985.
Je peux faire une version française s’il y a de la demande, ou répondre aux questions si certains points ne sont pas clairs.
[^] # Re: Merci
Posté par reynum (site web personnel) . Évalué à 2. Dernière modification le 08 juin 2016 à 22:43.
Par contre je viens de réfléchir et c'est étrange que bumblebee influe sur les perfs car normalement il se content de switcher à chaud entre le driver nvidia et intel donc il ne devrait y avoir de notion de performance ?
Edit : je viens de lire le message au dessus et de comprendre que manifestement j'avais pas tout compris.
kentoc'h mervel eget bezan saotred
[^] # Re: Merci
Posté par Archange . Évalué à 10.
Nope. L’idée, c’est que tu as deux cartes graphiques. L’une a l’écran (et tout ou partie des sorties vidéos dispos) de connecté dessus et est celle intégrée au CPU, l’autre est plus performante (on l’appelle dédiée) et a éventuellement une partie des sorties vidéos connectée dessus.
En temps normal la carte intégrée fait le boulot, et la carte dédiée est éteinte (ce point n’est déjà pas évident, mais passons).
Ensuite, de temps en temps, tu peux avoir envie de lancer des applications un peu plus lourdes, et donc de laisser la carte dédiée s’en occuper. Suffit de trouver un moyen de démarrer ces applis sur cette carte (pas trivial, plusieurs manières de faire). Seulement, même une fois ceci réussi, la carte dédiée ne peut pas afficher les images générées directement à l’écran, car elle n’est pas connectée à celui-ci. Il faut donc les transférer à la carte intégrée. Ce qui est à nouveau pas simple.
Pour Bumblebee, ça fonctionne ainsi : par défaut, un seul serveur X tourne, avec la carte intégrée. Si tout va bien, la carte graphique est éteinte. Quand tu déclares une application à lancer sur la carte dédiée avec optirun, bumblebeed (le daemon) démarre un second serveur X (sauf dans un cas particulier) avec uniquement la carte dédiée. Ensuite, selon le backend utilisé, il met en place un système de transfert.
Dans le cas de VirtualGL (l’ancien backend, qu’on garde juste au cas où), un client VGL est lancé sur le serveur X « intégré », et un serveur VGL sur le serveur X « dédié ». L’application est lancée sur le serveur X « dédié », et les images sont récupérées par le serveur VGL qui les transmet au client. C’est extrêmement lourd, et il faut savoir que VirtualGL sert normalement à faire tourner des applications à distance (le truc qu’on nous vend comme étant le futur depuis des années : un supercalculateur fait tourner ton application et te renvoie les images, dans le sens inverse il récupère les entrées type clavier/souris), donc c’est pas du tout prévu pour cet usage. Du coup, les performances sont pas au niveau du tout. Et les contraintes ne sont pas les mêmes.
Du coup, est arrivés Primus. L’idée ici, c’est un peu ce que fait la nouvelle libglvnd. En gros, on fait tourner l’application sur le serveur X normal, mais quand elle fait des appels graphiques (OpenGL), on les intercepte et redirige sur la carte dédiée (le second serveur X est toujours nécessaire pour des recevoir ces appels). On récupère les résultats en sortie et les réinjecte dans l’application.
Tout ça est lourd dans les deux cas, car ça implique plein de copies en plus. Du coup, les performances sont limitées, notamment quand la résolution d’écran est grande, car la taille des images à copier l’est d’autant plus.
De l’autre côté, il y a PRIME (et le fonctionnement natif d’Optimus sous Windows, qui ne doit pas être très loin). Ici, tout se passe à un niveau beaucoup plus bas : la mémoire partagée des cartes graphiques. Pour les applications spécifiées, la carte intégrée écrit directement les appels qu’elle reçoit dans la mémoire de la carte dédiée, et cette dernière écrit directement les résultats de ces appels dans la mémoire de la carte intégrée. En gros, PRIME permet à chaque carte d’écrire dans la mémoire de l’autre. Après il y a plein de subtilités et d’autres choses à considérer, mais ça donne l’idée générale. L’important, c’est que c’est beaucoup plus propre d’un point de vue technique, et qu’en termes de performances on ne peut pas faire mieux.
PRIME dispose aussi d’un mode dit « reverse », dans lequel une carte peut utiliser les sorties vidéos de l’autre. Du coup, tu peux aussi tout faire tourner sur la carte dédiée et écrire dans la mémoire de l’autre pour l’affichage uniquement. C’est ce mode qui est utilisé par Nibel et le paquet nvidia-prime.
[^] # Re: Merci
Posté par xcomcmdr . Évalué à 1.
Rajoute :
- Plein de jeux avec des bugs graphiques ou injouables même si on est sûr et certains d'utiliser le bon GPU et le bon pilote, et d'avoir à la fois essayé primusrun et optirun.
Exemples : Wasteland 2 (on ne voit rien) et War for the Overworld (on ne voit pas où on creuse).
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Merci
Posté par Archange . Évalué à 3.
As-tu pensé à reporter ces problèmes ici : https://github.com/amonakov/primus/issues ? ;) Ou a minima là : https://github.com/Bumblebee-Project/Bumblebee/issues. Même si ici le premier est plus indiqué.
[^] # Re: Merci
Posté par xcomcmdr . Évalué à 2.
Oui, et rien n'a été fait car le problème est du côté du pilote Intel (il paraît) mais rien n'a bougé pendant des années et pourtant quand je l'ai signalé tout ce que j'ai eu comme réponse c'est "c'est déjà signalé".
Après des années avec ce problème. Je suis retourné sous Windows. Problème disparu, usage automatique du bon GPU, aucun problème de perf.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Merci
Posté par Archange . Évalué à 1.
Je parlais plus spécifiquement des problèmes liés aux deux jeux que tu cites. Je n’en trouve pas trace dans les deux systèmes de suivi des bugs, donc ça m’aiderait beaucoup si tu pouvais me donner des liens précis. ;)
Et sinon, comme dit en-dessous, je suis d’accord que c’est un domaine où il y a encore des (gros) progrès à faire par rapport à Windows.
[^] # Re: Merci
Posté par Nibel . Évalué à 0.
Les deux fonctionnent sur ma configuration Optimus. Peut-être un problème d'interface chaise-clavier ?
Blague à part, je n'ai jamais rencontré aucun problème et il m'arrive même d'avoir de meilleurs performances sous Wine que sous un Windows natif…
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Merci
Posté par xcomcmdr . Évalué à 1.
Aucune chance, vu que ça arrivait quelque soit la distrib' et le pilote, et à plein de personnes sur les forums Steam du jeu.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Merci
Posté par Archange . Évalué à 7.
En fait le problème de vsync vient plutôt de chez Intel, qui n’en a pas grand chose à cirer apparemment car dans le fond Optimus c’est pas trop leur problème.
Le switch dynamique, c’est un problème légal pour ce que j’en sais, seuls les drivers compatibles GPL peuvent utiliser l’interface noyau qui permet de faire cela. Du coup ça fonctionne avec nouveau (et plutôt très bien, extrêmement simple d’utilisation surtout avec DRI3 et le .drirc), mais ne pourra pas fonctionner avec nvidia tant qu’il ne sera pas libre. C’est-à-dire probablement jamais.
Après, je suis d’accord que Nvidia aurait pu (et pourrais toujours évidemment) aider un peu plus au support de cette techno, mais ils n’ont pas rien fait non plus.
[^] # Re: Merci
Posté par Frédéric Massot (site web personnel) . Évalué à 5.
AMD travaille sur le support des premières cartes GCN 1.0 "Southern Islands" par leur nouveau pilote AMDGPU, pour les cartes pré-GCN on reste avec le pilote Radeon :
[^] # Re: Merci
Posté par xoddark . Évalué à 2.
Peut être qu'il n'y a pas d'amélioration pour les gpu AMD anciens (pré-GCN) par ce qu'il n'y a pas besoin.
Premièrement le pilote radeon fonctionne plutôt bien/voir très bien. Mon ordinateur portable a un GPU Evergreen (radeon HD 57730) et je n'ai pas de problème avec les pilotes libre. J'utilise Gnome 3, je lit un peut de vidéo, et je lance parfois des jeux (Portal 2, ou Flatout fonctionne bien par exemple).
Ensuite aujourd'hui c'est surtout dans Mesa qu'il y a des améliorations (nouvelles extension OpenGL, implémentation d'OpenCL, amélioration de la décompression vidéo).
Bon bien sur le pilote n'est surement pas parfait, mais je dirais que le fait qu'il n'y ai pas systématiquement des changements a chaque nouvelle version de noyaux que c'est mauvais signe, au contraire.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Merci
Posté par xcomcmdr . Évalué à -3. Dernière modification le 07 juin 2016 à 22:48.
A qui le dis-tu !
C'est bien pour ça que j'ai remplacé Linux par Windows XP sur mon vieux PC à base de Pentium 3 + GeForce 4.
Non seulement c'est beaucoup plus rapide à booter, mais en plus c'est stable et performant et j'ai la dernière version de Firefox ! :p
Je ne suis plus bloqué soit avec une ancienne version de Xorg qui rame, soit avec Nouveau qui ne marche pas là dessus.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Merci
Posté par xcomcmdr . Évalué à -6.
Ah, je dis la vérité, mon expérience, et je suis "inutilé".
Bravo.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Merci
Posté par Nibel . Évalué à 4.
Tu es "inutilé" parce que ton interlocuteur parle de la gestion des vieux GPU pas top et toi de la gestion du vieux matériel (que tu considères pas top, ce qui est techniquement faux).
Tout comme dire qu'un XP est plus rapide à booter qu'une Linux sur une vieille config. Ca dépend de ta distro et de ce que tu y mets dedans… Pour ma part, vu qu'Arch n'est plus build pour architecture x32 j'utilise ArchBang (i686) et XP est bien loin de booter plus vite sur mes vieilles machines (HP Pavilion dv9081 avec un Intel T5500 et une Nvidia GeForce GO 7600 ainsi qu'un Dell Inspiron avec un Intel Core 2 Duo).
Et dire qu'un XP est stable et performant… quand l'OS n'est plus supporté depuis 2014, il fallait l'oser.
Il est toujours intéressant d'avoir le retour d'expérience d'utilisateurs, d'autant plus quand ceux-ci apportent de la matière à leurs dires. Mais dénigrer pour le plaisir de dénigrer, ce ne l'est pas.
Et j'ai aussi la dernière version de Firefox sur mes vieilles bécanes :
Et le pilote proprio nvidia-96xx-dkms gère parfaitement les Nvidia GeForce 4 en théorie (mais là je n'ai pas de preuve). Nouveau ne semble pas correspondre à ton besoin.
La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.
[^] # Re: Merci
Posté par xcomcmdr . Évalué à 0. Dernière modification le 09 juin 2016 à 19:14.
Je parlais de la même chose.
Et un vieux GPU, c'est un vieux matériel. Jusqu'à preuve du contraire…
La différence entre vieux GPU et vieux matériel est pour le moins… subtile !
A partir du moment où y'a Xorg, XP le bat à plate couture sur mon Pentium 3.
Que cette réalité te dérange ne l'invalide en rien.
Et c'est bien plus puissant que mon P3, donc ça n'a rien à voir.
Ben oui, sur ce matos là XP est à l'usage plus rapide et est très stable de toutes façons.
Ça n'a absolument rien à voir. L'OS n'a plus de mises à jours de sécurité, soit.
Mais ça ne le rend pas plus lent ni plus plantogène.
Je ne dénigre pas.
Je n'ai pas dit le contraire. Seulement il impose d'utiliser une ancienne version de Xorg, et était de plus en plus difficile à compiler (y'a une grosse partie binaire, mais y'a une petite interface/whatever à compiler avec) avec les nouvelles versions de Linux.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: Merci
Posté par Xavier Verne (site web personnel) . Évalué à 0.
Pascal -> pascale ?
[^] # Re: Merci
Posté par Pazns . Évalué à -1.
Ça serait un peu tard, les modèles 1060 ne même pas encore annoncés alors que les lapins en chocolat ne sont déjà plus dans le placard.
# Coupe-feu ?
Posté par Renault (site web personnel) . Évalué à 4.
Pare-feu n'est pas techniquement plus juste ?
Le traducteur s'est un peu laissé aller. ;)
[^] # Re: Coupe-feu ?
Posté par BAud (site web personnel) . Évalué à 4.
il y avait aussi garde-barrière :D J'ai déjà vu pare-feu et coupe-feu, pas celui-là néanmoins ;-)
# Petites erreurs (ou pas ?)
Posté par RyDroid . Évalué à 5.
La partie "En bref" est un copier-coller de l'introduction ou presque, pas vraiment utile.
"NVIDIA a enfin rendu public à la fois les firmwares nécessaires à la prise en charge de la 3D pour la 2e génération de GPU Maxwell (sortie le 1er juin 2015) ! Ces firmwares étant signés par NVIDIA, il était impossible pour les développeurs de Nouveau de produire leurs propres firmwares comme ils le faisaient pour les générations précédentes." (emphase ajoutée) Les firmwares et les clés de signature ?
[^] # Re: Petites erreurs (ou pas ?)
Posté par Martin Peres (site web personnel) . Évalué à 2.
Le "à la fois" est de trop.
# NUMA != multi-socket
Posté par Brice Goglin . Évalué à 10.
NUMA est orthogonal à multi-socket. Il y a 10 ans, on avait plusieurs processeurs par noeud NUMA sur Itanium. Maintenant c'est le contraire, les processeurs sont NUMA en interne, sans même être dans une machine multi-processeur. Par exemple, sur un bi-processeur Xeon E5v3, il peut y avoir 4 noeuds NUMA, 2 dans chaque processeur:
https://pbs.twimg.com/media/Ce7r-DoWQAUlE0l.jpg:large
Les processeurs pour serveur des autres constructeurs qu'Intel suivent la même tendance.
Ca dépend des applications… Pour les applications qui font du gros streaming mémoire, peut-être. Pour les applications qui utilisent un jeu de données relativement petit (de l'ordre de quelques megaoctets ou dizaines de mégaoctets, de nos jours), ca tient dans le cache, elles s'en fichent du débit mémoire. Et si on garde les processus proches au lieu de les répartir, le partage mémoire entre eux sera plus rapide.
C'est le genre d'info que l'ordonnanceur ignore quand il répartit les processus. D'où la nécessité de binder les tâches à la main depuis l'espace utilisateur quand on fait du HPC.
# FS
Posté par KiKouN . Évalué à 7.
CeFS, je ne connais pas. Je suppose que c'est Ceph.
En parlant de Ceph, je n'ai pas trouvé si OrangeFS supporté un mode de type raid5,6 ou erasure comme Ceph. Quelqu'un aurait-il des infos la-dessus ?
# GPIO
Posté par Benjamin Henrion (site web personnel) . Évalué à 6.
Une autre grosse nouvelle est la nouvelle interface pour les GPIOs, qui seront maintenant exposées via /dev/gpioXXX, autrement dit un gain de performance.
[^] # Re: GPIO
Posté par Juke (site web personnel) . Évalué à 10.
Pourquoi ça implique un gain de performance ?
[^] # Re: GPIO
Posté par steph1978 . Évalué à 2.
Pareil.
Gain en utilisabilité, sûr.
On pourra faire des scripts shell qui liront ou écriront sur les fichiers.
C'est donc une très bonne nouvelle.
Mais pourquoi gain en performance ?
# Panneau d'affichage
Posté par Antoine . Évalué à 7.
"Panneau d'affichage" semble la traduction littérale de "display panel", cependant cette expression n'est guère utilisée en français. Pourquoi pas simplement "écran" ?
[^] # Re: Panneau d'affichage
Posté par Martin Peres (site web personnel) . Évalué à 2.
Je suis d'accord que c'est pourri comme traduction. Mais quand on parle d'écran, on pense aux écrans HDMI et DP ou VGA qui ne nécessitent pas de pilotes… Du coup, je suis toutes ouïes si tu as une meilleure proposition :)
[^] # Re: Panneau d'affichage
Posté par xcomcmdr . Évalué à 5. Dernière modification le 08 juin 2016 à 16:12.
Et pourquoi c'est pas le cas pour les autres types d'écrans ? Que sont ces Display Panels, d'ailleurs ?
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
# Économies d'énergie
Posté par Antoine . Évalué à 6.
A-t-on une idée de l'impact concret des économies d'énergie apportées sur processeurs et GPU Intel ? Genre un benchmark de l'autonomie sur batterie dans certaines conditions…
[^] # Re: Économies d'énergie
Posté par Archange . Évalué à 10.
Ça dépend à quoi tu fais référence. Si c’est côté ordonnanceur, je ne peux pas encore répondre à cela (le paquet est bloqué dans [testing] pour l’instant sur Arch — qui se trouve être ma distro — à cause d’une régression des applications Qt5), mais a priori rien de fondamental. Le futur schedutil de cpufreq devrait en revanche être assez intéressant.
Côté GPU, le Panel Self-Refresh (PSR), « c’est de la bombe ». La conso de mon laptop en utilisation standard passe de ~13.5W à ~8.5W. Non négligeable, extrêmement appréciable. Je comprends mieux la différence d’autonomie entre Windows et Linux que j’observais à l’époque où j’avais encore un double boot. D’ailleurs, le noyau 4.6 apporte aussi la gestion d’énergie des contrôleurs AHCI, mais c’est expérimental. Pas encore eu le temps de tester car cela demande quelques précautions, mais a priori là aussi le gain ne devrait pas être négligeable.
Ce qu’il faut comprendre, c’est que de nos jours le « niveau d’énergie » (état) de beaucoup de composants dépend de celui d’autres, et que parfois rajouter la gestion d’un composant permet à beaucoup d’autres d’atteindre des niveaux encore plus bas. On pourra lire cette référence (en anglais) sur le sujet, par un développeur du noyau en partie responsable de ces améliorations : https://mjg59.dreamwidth.org/34868.html.
[^] # Re: Économies d'énergie
Posté par ff9097 . Évalué à 2.
Et donc en terme d'autonomie, tu saurais évaluer le gain ?
[^] # Re: Économies d'énergie
Posté par Archange . Évalué à 10.
Oui, évidemment, puisque la consommation est directement liée l’autonomie. ;) En utilisation standard, disposant d’une batterie de 61 Wh, je passe de 4 h 30 à 7 h 20 d’autonomie (ce que j’observe dans la pratique, et c’est assez agréable pour les trajets en train que je fais régulièrement). Et là je me dis que si j’avais eu un peu plus de sous à l’époque, j’aurais pu prendre la version SSD + batterie 91 Wh de mon PC (au lieu de HDD + batterie 61 Wh car le HDD prend de la place), et j’aurais eu facilement 11 ou 12 h d’autonomie.
Ce que j’entends par utilisation standard : quelques onglets dans mes terminaux, avec vim ouvert sur quelques fichiers, connecté en Wi-Fi avec Firefox et une quinzaine d’onglets, luminosité de l’écran à 50 % (soit 200 cd·m⁻² dans mon cas).
Évidemment, le gain exact dépendra de la machine de chacun (notamment, il faut forcément une machine pas trop vieille pour profiter de tout cela), de l’usage… Mais pour les machines concernées, le gain est toujours appréciable.
Et bien sûr, dans un jeu vidéo qui fait du 60 IPS, ça ne change rien, vu qu’il n’y a pas d’économies d’énergie à faire dans cette situation…
[^] # Re: Économies d'énergie
Posté par ff9097 . Évalué à 2.
C'est énorme :D
[^] # Re: Économies d'énergie
Posté par Archange . Évalué à 5.
Oui, et comme dit l’article, le gain est dans une fourchette 29 → 85 % sur un ensemble de systèmes testés. Ce qui n’est pas dit, c’est un gain de quoi, mesuré par rapport à quoi. De mémoire, il s’agit de la baisse de consommation, par exemple, en passant de 13.5 W à 8.5 W, j’ai gagné 37 %, mais mon autonomie, elle, en passant de 270 à 440 minutes, a obtenu un gain de 63 %. Imagine donc pour les systèmes concernés par des gains de l’ordre de 85 % ! (Réponse : autonomie multipliée par 6.66, soit un gain de 566 %)
[^] # Re: Économies d'énergie
Posté par KiKouN . Évalué à 3.
Si tu est encore un HDD, prend un SSD, ça va te changer la vie.
[^] # Re: Économies d'énergie
Posté par Archange . Évalué à 3.
Je sais, mais ça coûte encore un peu cher pour moi. Mais c’est prévu (en fait, pour être exact, j’ai un SSD M.2 de 32 Gio qui héberge le système, et un HDD de 1 Tio pour le /home et le /var, mais tout sur SSD ce serait quand même mieux pour beaucoup de choses — et accessoirement, entre SSD+HDD et SSD tout seul, avec dans les deux cas le SSD au format M.2, ça fait quand même moins de consommation).
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Économies d'énergie
Posté par barmic . Évalué à 5.
Pour bénéficier de ça, il faut juste avoir un noyau 4.6 ou il faut aussi avoir le code userspace qui va avec (le driver coté Xorg) ?
Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
[^] # Re: Économies d'énergie
Posté par Archange . Évalué à 3.
Rien du côté Xorg à ma connaissance, c’est le pilote KMS (côté noyau, donc) qui est concerné.
Par contre maintenant que je suis sur le 4.6, j’ai une régression quelque part qui fait que mon portable est grimpé à 15 W de consommation au lieu de 8.5 (avec le noyau 4.5 et psr/fbc réglés à 1), ce que je corrèle avec le fait qu’il ne descend plus dans l’état pc6…
[^] # Re: Économies d'énergie
Posté par Martin Peres (site web personnel) . Évalué à 3.
Malheureusement, c'est pas le cas. Le pilote xf86-video-intel faisait un truc pas trop légal jusqu'à très récemment… Du coup, faut un pilote à jour pour en profiter si je me souviens bien.
[^] # Re: Économies d'énergie
Posté par gpe . Évalué à 2.
Je viens de passer en 4.6 sur debian testing et je n'ai constaté aucun gain de conso sur mon T420 avec CG Intel … :(
[^] # Re: Économies d'énergie
Posté par ff9097 . Évalué à 1.
Il faut probablement une CG plus récente
[^] # Re: Économies d'énergie
Posté par gpe . Évalué à 2.
Possible effectivement. C'est un core i5-2520M que j'ai actuellement.
[^] # Re: Économies d'énergie
Posté par antistress (site web personnel) . Évalué à 5.
Quand tu lis le message des modifications de cette version du mainteneur, ça ne concerne que les derniers procs pour commencer, avant d'être étendu aux générations précédentes.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Économies d'énergie
Posté par rpnpif . Évalué à 4.
Moi je confirme que la température de mon AMD HD a baissé et la performance a un peu augmenté.
Mon vieux EEEPC d'ASUS s'en porte aussi assez bien.
Le 4.6 est un bon cru (sous Debian Jessie-backports).
# Commentaire supprimé
Posté par Yvesmarcer . Évalué à -2. Dernière modification le 22 juin 2016 à 12:27.
Ce commentaire a été supprimé par l’équipe de modération.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.