Sortie du noyau Linux 5.0

Posté par  (Mastodon) . ÉditĂ© par Julien Jorge, palm123, Davy Defaud et BenoĂźt Sibaud. ModĂ©rĂ© par Ontologia. Licence CC By‑SA.
99
4
mar.
2019
Noyau

La sortie de la version stable 5.0 du noyau Linux a Ă©tĂ© annoncĂ©e le 4 mars 2019 par Linus Torvalds. Le nouveau noyau est, comme d’habitude, tĂ©lĂ©chargeable sur les serveurs du site kernel.org. Linus a dĂ©cidĂ© de faire une RC 8, ce qui est relativement inhabituel. Le dĂ©tail de quelques‐unes des Ă©volutions et nouveautĂ©s se trouve dans la seconde partie de la dĂ©pĂȘche.

Sommaire

En bref

Pourquoi Linux 5.0 ? Rien à dire de particulier, rien de remarquable, c’est juste un changement de version.

Annonces des versions candidates par Linus Torvalds

RC-1

Annonce de la premiĂšre candidate, le 6 janvier. Note Ă  propos des vacances de fin d’annĂ©e, et du calme apparent. La quantitĂ© de modifications est jugĂ©e normale.

Linus annonce Ă  cette occasion que la 4.21 deviendra la 5.0, et en donne l’explication : il n’y a pas de raison particuliĂšre, alors faisons‐nous Ă  l’idĂ©e, ou notre propre raison.

RC-2

Annonce de la seconde candidate, tout est normal : la fenĂȘtre de fusion est respectĂ©e, sauf pour quelques cas pas plus nombreux qu’à l’habitude, le nombre des changements, leur rĂ©partition et la quantitĂ© de code sont eux aussi dans les standards habituels. Quelques amĂ©liorations du cĂŽtĂ© des outils de suivi des performances sont notĂ©es tout particuliĂšrement.

RC-3

Annonce de la troisiĂšme candidate. Ici on y trouve une attention particuliĂšre sur la pile rĂ©seau elle‐mĂȘme, ainsi que sur les pilotes rĂ©seau. Quelques changements cĂŽtĂ© architectures, surtout MIPS et PowerPC.

RC-4

La quatriĂšme candidate a un cycle un peu excitĂ©. Linus signale que plus de demandes d’intĂ©gration sont survenues au dernier moment, et que certaines ont Ă©tĂ© refusĂ©es, mais rien d’anormal.

RC-5

Le calme revient pour le cycle de cette cinquiÚme candidate. Un tiers des changements a lieu dans les pilotes. Et Linus parle encore de vacances.

RC-6

Pour la sixiĂšme, c’est toujours les pilotes rĂ©seau qui sortent du lot. C’est sur des rails que cette sortie se fait, une belle candidate de prime abord.

RC-7

La septiÚme montre des statistiques avec presque la moitié des changements pour les pilotes. Et beaucoup de changements atomiques, petites modifications : on est vraiment dans la correction de bogues et les petites améliorations.

RC-8

Surprise, la RC-7 ne suffira pas, un grand nombre de changements arrive d’un coup. Ce ne sera donc pas une version finale, elle sera estampillĂ©e RC-8, repoussant ainsi d’un cycle la sortie de cette 5.0. Cette candidate n’est pas Ă©norme mais propose plus de changements que la prĂ©cĂ©dente. Une semaine de calme sera bienvenue avant la sortie officielle.

Les nouveautés

Des problùmes de performances ?

Michael Larabel a constatĂ© de sĂ©vĂšres rĂ©gressions de performances avec ce noyau 5.0, à tous les niveaux. Tellement qu’on peut lĂ©gitimement se demander s’il ne se serait pas tout simplement trompĂ© dans les options de compilation ? Notons que ces tests de performance ont Ă©tĂ© faits avant la sortie du noyau, avant mĂȘme les derniĂšres RC.

Architectures

x86 & x86-64, Intel et AMD

Ajout de la prise en charge des extensions QoS « QualitĂ© de Service de la plate‐forme » permettant d’avoir une surveillance de l’usage des consommations de certaines ressources, de les allouer et les limiter sĂ©parĂ©ment, pour la nouvelle gĂ©nĂ©ration des processeurs AMD, dite « EPYC ». Cette possibilitĂ© n’est pas seulement ajoutĂ©e, elle est mise en coexistence avec le gestion du RDT pour les processeurs Intel. L’entrĂ©e RESCTL est une nouvelle structure accueillant Ă  la fois et INTEL RDT et AMD QoS. La gestion du cache est Ă©galement mise Ă  jour pour suivre cette Ă©volution.

Toujours du travail pour Ă©liminer empĂȘcher au mieux les failles de la famille « Spectre v2 », par exemple pour les multiples processeurs AMD ayant chacun des spĂ©cificitĂ©s avec leur STIBP (Single Thread Indirect Branch Predictor)

Enfin, de nombreux ajouts pour les ordinateurs portables, des raffinements tels que les touches d’accĂšs rapide pour WMI chez Huawei ou encore le contrĂŽle visuel par DEL (LED) lors de la dĂ©sactivation du micro pour les portables DELL, et l’équivalent pour les Lenovo.

ARM

Beaucoup de nouveaux systĂšmes mono-puces (SoC — System on Chips) sont intĂ©grĂ©s (NXP/Freescale i.MX7ULP, i.MX8 64 bits avec Cortex A3 et prise en charge de la vidĂ©o 4K, Qualcomm QCS404, Allwinner R40/T3, etc.), ainsi que seize nouvelles plates‐formes (nouveau Linksys EA600 par exemple, i.MX mtrion et i.MX 7D, Rockchip BQ edition, etc.).

La grande famille ARM est également touchée par « Spectre v2 » et a donc aussi son lot régulier de correctifs pour cela. Cette version 5.0 intÚgre les instructions dites « SB » (speculation barrier) pour la génération ARM v8.5. Voir le commit initial.

IntĂ©gration des algorithmes de chiffrement XChaCha12 et XChaCha20 pour tous, ainsi que la gestion de l’accĂ©lĂ©ration matĂ©rielle via NEON pour NHPoly1305.

ARM64 bénéfice aussi de la plupart de ces avancées, auxquelles il faut ajouter, entre autres, la gestion de KASLR et la vérification de signatures.

Enfin, l’architecture particuliĂšre « big.LITTLE » reçoit une amĂ©lioration pour la consommation d’énergie dans l’ordonnanceur de tĂąches. Les tĂąches rĂ©veillĂ©es le sont toujours en prioritĂ© sur les cƓurs de processeur les moins gourmands en Ă©nergie dans cette architecture dissymĂ©trique. Son inclusion dans le noyau commence avec ce correctif et est maintenant complĂšte. Une architecture « big.LITTLE » sur ARMv8 propose jusqu’à quatre cƓurs de processeur LITTLE en Cortex A-53 (!) et jusqu’à seize cƓurs de processeur Cortex A-57, liĂ©s en diffĂ©rentes configurations : autant dire que « ça envoie du bois ».

PowerPC

Belle avancĂ©e pour le PowerPC, avec l’ajout de la gestion des Huge Pages de 8 Mio (et celles de 512 Kio). Pour rappel, le processeur alloue par dĂ©faut de la mĂ©moire vive par page de 4 Kio. Plus il y en a et plus de temps processeur est pris pour trouver la bonne page Ă  la demande. Les Huge Pages proposent donc des « chunks » plus gros et des pages plus larges. Les applications qui en bĂ©nĂ©ficient sont surtout les bases de donnĂ©es, la virtualisation, et l’usage de diffĂ©rents procĂ©dĂ©s de cache mĂ©moire (memcached par exemple).

Un PowerPC a également du travail pour combattre « Spectre v2 » : le processeur NXP Book3E de chez Freescale.

Autres

Ajout d’une prise en charge prĂ©liminaire pour Loongson 3A R2.1 et amĂ©lioration du cĂŽtĂ© de ptrace pour les MIPS. Du cĂŽtĂ© de RISC-V, la gestion pour l’audit est lĂ .

Gestion de la mémoire

Parmi les changements et améliorations dans la gestion de la mémoire vive :

RĂ©organisation du tableau de l’OOM Killer

L’OOM Killer (out of memory management) est un mĂ©canisme s’enclenchant lorsqu’il n’y a plus aucune mĂ©moire disponible : le noyau construit un tableau de victimes potentielles pour tuer celles prĂ©sentant Ă  la fois une forte consommation de ressources et ayant une fonction non essentielle. Le noyau prĂ©serve ainsi le systĂšme et les services rendus. Cas d’exemple : une fuite mĂ©moire dans un script Python utilisant gdal, au lieu de faire un Ă©cran bleu, ce script sera tuĂ© et le systĂšme continuera d’ĂȘtre opĂ©rationnel pour les autres — mais cette rĂ©organisation ne changera pas l’OOM killer en l’adaptant pour les machines de bureau : il continuera de tuer joyeusement et avec bonne humeur votre LibreOffice.

RĂ©duction de la fragmentation des Transparent Huges Pages

Du cĂŽtĂ© des Transparent Huges Pages (THP), la fragmentation a Ă©tĂ© rĂ©duite de 90 %, amĂ©liorant probablement leurs performances. Il ne s’agit pas d’une nouveautĂ© Ă  proprement parler mais de la suite d’un travail constant. Si discuter des Ă©vitements de fragmentations de la mĂ©moire vive dans un contexte d’usage des THP ne vous fait pas mal au crĂąne, ce commit explique en dĂ©tails les enjeux et les amĂ©liorations apportĂ©es dans cette version.

Retours d’information des dĂ©faillances mĂ©moire

Des amĂ©liorations sur les retours d’information en cas de dĂ©faillance d’une mĂ©moire, permettant de mieux identifier le problĂšme, voir ce commit.

Option de dĂ©sactivation de kmemleak lors de l’amorçage

Une nouvelle option permettant de dĂ©sactiver le kmemleak Ă  l’amorçage du systĂšme a Ă©tĂ© ajoutĂ©e. Pour mĂ©moire, kmemleak propose une façon pour identifier les fuites mĂ©moire des applications en espace utilisateur (d’autres mĂ©thodes existent, avec Valgrind par exemple). Ce procĂ©dĂ© scanne la mĂ©moire vive pĂ©riodiquement. Offrir sa dĂ©sactivation permet d’allĂ©ger le processeur pour des environnements et systĂšmes oĂč le dĂ©bogage n’est pas ciblĂ© ou utilisĂ©.

Sécurité

Nouvelles commandes TPM2

De nouvelles commandes spécifiques à TPM2 ont été intégrées, conformément au TCG 1.3x.

SELinux

Correction d’une erreur avec SELinux qui empĂȘchait par dĂ©faut le montage de sous‐volumes, alors que l’action sur le volume initial/principal a dĂ©jĂ  Ă©tĂ© vĂ©rifiĂ©e et autorisĂ©e. Ceci causait des problĂšmes avec l’auto‐monteur automount, AutoFS, et NFS. DorĂ©navant, lorsqu’un sous‐volume prĂ©sente un drapeau MS_SUBMOUNT, SELinux autorise son montage.

SECCOMP

AmĂ©lioration pour le systĂšme SECCOMP : si un conteneur demande, par exemple, un init_module(), alors SECCOMP va analyser l’image du module et charger le correspondant cĂŽtĂ© hĂŽte. Autre cas, autre exemple : un conteneur n’a pas accĂšs Ă  mknode(), et personne ne veut d’un systĂšme de liste blanche pour des usages lĂ©gitimes (de type /dev/null ou /dev/zero) et mount a dĂ©jĂ  tout le nĂ©cessaire pour rĂ©pondre Ă  ce besoin. Une trap SECCOMP a donc Ă©tĂ© ajoutĂ©e pour l’espace utilisateur afin de notifier une autre tĂąche qu’un filtre SECCOMP particulier vient d’ĂȘtre dĂ©clenchĂ©. ConcrĂštement, SECCOMP peut donc maintenant dĂ©lĂ©guer des politiques en espace utilisateur.

Chiffrement NHPoly1305, XChaCha12 et XChaCha20

Les algorithmes de chiffrement NHPoly1305, XChaCha12 (lĂ  surtout pour Adiantum) et XChaCha20 ont Ă©tĂ© intĂ©grĂ©s. Ce document (en anglais) sur cr.yp.to, prĂ©sente assez simplement les informations sur ChaCha. La gestion de l’accĂ©lĂ©ration matĂ©rielle pour ces mĂȘmes algorithmes a Ă©tĂ© ajoutĂ©e dans le pilote CCAM (crypto_dev_fsl_caam).

Chiffrement AEAD pour le pilote Nitrox

Ajout de l’algorithme AEAD pour le pilote Nitrox, utilisĂ© par exemple sur certaine cartes Marvell, aussi dans une architecture « LiquidIO IPSec » (via Cavium) avec certaines cartes rĂ©seau du mĂȘme fabricant.

ARM TrustZone CryptoCell

L’ARM TrustZone CryptoCell 703, Ă©dition chinoise du 713, car n’intĂ©grant que les algorithmes validĂ©s par l’office chinois OSCCA, est intĂ©grĂ©. Sa version « complĂšte » 713 Ă©galement. Voir cette ressource pour une comparaison rapide.

kexec

kexec est une ancienne capacitĂ© de charger un second noyau en mĂ©moire vive, pour rĂ©amorcer le systĂšme dessus sans passer par les phases d’initialisation des BIOS, micrologiciels et EFI longues, trĂšs longues, de certaines machines.
kexec_load_file() tient maintenant compte du nouveau trousseau de clefs nommĂ© .plateform de SecureBoot. Il est aussi utile pour d’éventuels modules de sĂ©curité qui peuvent utiliser ce nouveau trousseau pour vĂ©rifier, autoriser et interdire les images noyau chargĂ©es, demandĂ©es par un appel kexec_load_file().

Plaisirs d’administrateurs systùme

Les administrateurs systÚme bénéficient des nouveautés suivantes :

  • l’ajout de deux marques spĂ©cifiques dans le systĂšme fanotify permettant de distinguer une exĂ©cution : fan_open_exec et fan_open_exec_perm — tous les administrateurs systĂšme utilisant ce sous‐systĂšme via des utilitaires tels qu’inotify, incron et audit en seront ravis ;
  • l’activation dans la hiĂ©rarchie par dĂ©faut d’un contrĂŽleur CPUSET, concernant la prise en charge des Cgroups version 2 ; introduit il y a plus de dix ans, mais optionnel et laissĂ© Ă  la discrĂ©tion des admins, il fait maintenant son apparition dans une configuration « de base », en options minimales — certaines de ses possibilitĂ©s pourraient Ă  l’avenir migrer dans le contrĂŽleur Cgroup de mĂ©moire ou le contrĂŽleur Cgroup de processeur ;
  • l’ajout d’une possibilitĂ© de configuration des informations affichĂ©es lors d’une panique, grĂące au nouveau panic_print.

Périphériques et pilotes

NVMe over Fabric

L’implĂ©mentation du NVMe over Fabric (NVMe pour « mĂ©moire vive non volatile via bus PCI Express ») : concrĂštement il s’agit de s’affranchir des limites du port PCI Express en termes de distance physique, et de mettre Ă  disposition du systĂšme des NVMe lointains via les rĂ©seaux TCP/IP.

Audio

Du cÎté du son, dans le noyau, nouvelles prises en charge et améliorations habituelles dans la pile générique HD_AUDIO, ainsi que pas mal de boulot sur les systÚmes monopuces (SoC) présentés sur différents connecteurs, mais également une gestion préliminaire du AK4118 .

Pilotes de cartes graphiques

AMD et sa Radeon VII, semble bien ĂȘtre le meilleur choix pour les joueurs libristes et plus gĂ©nĂ©ralement de tous les joueurs sous GNU/Linux. Cette carte et son pilote libre amdgpu, accompagnĂ©e de Mesa 3D, accroche en performance une NVIDIA RTX 2080 avec son pilote propriĂ©taire. OK ? OK !

AMD
  • gestion du FreeSync, les frĂ©quences dynamiques de rafraĂźchissement d’écran (permettant d’éviter certains effets visuels indĂ©sirables et aussi d’allĂ©ger la consommation), dans sa version « FreeSync 2 HDR », pour le pilote AMDGPU, et aussi un correctif, supprimant un petit bogue, acceptĂ© en toute derniĂšre minute ;
  • la rĂ©initialisation du processeur graphique est fonctionnelle pour les CI, VI et Soc15, mais aussi sur les processeurs graphiques intĂ©grĂ©s aux cartes mĂšres (dGPU pour discrete GPU) ; si un traitement atteint un dĂ©lai de grĂące, le processeur graphique peut ĂȘtre rĂ©initialisĂ©, sans autre problĂšme ;
  • gestion pour l’espace utilisateur (via sysfs) de l’exposition des adresses mĂ©moire des pages dites « BO doorbells » (un lien explicatif, bien qu’ancien et n’ayant pas de rapport direct avec cette nouvelle prise en charge, historique et intĂ©ressant à lire) ;
  • gestion de la DCC (Delta Color Compression) : jusqu’à prĂ©sent ce n’était pas manipulable en espace utilisateur, ce correctif l’active et l’expose Ă  la fois pour la libdrm et l’AMDGPUDM, et ceci sans ajouter d’appels ioctl() supplĂ©mentaires, ce qui devrait impacter favorablement les performances et la gestion de l’énergie ;
  • prise en charge des Vega 12 et Polaris 12 pour KFD (kernel fusion driver, issu de HSA/Compute) ; d’autres Vega, dont Vega 20, arrivent au pas de charge — lire cet ancien commit pour en savoir plus, aussi sur la fusion de KFD dans AMDGPU ;
  • et quelques autres, dont une mise Ă  jour de micrologiciels SMU pour quelques variantes des GFX9, la gestion du PowerPlay pour les nouvelles Polaris, ajout de l’identifiant PCI pour les derniĂšres Vega M, mais aussi un raffinement correctif pour l’amorçage « seamless » (un « amorçage du systĂšme silencieux et parfait visuellement ») avec les processeurs graphiques intĂ©grĂ©s aux cartes mĂšres (dGPU).
Intel
  • ajout de l’identifiant PCI pour les derniĂšres Amber Lake ;
  • gestion des espaces colorimĂ©triques YCbCr 4:2:0 et 4:4:4 pour les puces LPSCon par le pilote i915 et ajout de la transmission des informations AVI (la spĂ©cification semble si compliquĂ©e que de nombreux vendeurs de puces LPSCon le font chacun Ă  leur maniĂšre, nous avons donc lĂ  Ă  la fois un modĂšle gĂ©nĂ©rique et des subtilitĂ©s pour chaque marque de LPSCon) ;
  • et quelques autres petites amĂ©liorations, par exemple le mĂ©lange du plan Alpha, il pouvait y avoir des erreurs lors de l’usage d’une transparence totale ou a contrario d’une opacitĂ© totale.
NVIDIA et autres

De nombreuses autres cartes graphiques bĂ©nĂ©ficient d’amĂ©liorations. Nouveau ajoute le gestion initiale de la gestion des modes d’affichage (modsetting) pour la nouvelle gĂ©nĂ©ration des NVIDIA Turing 104 et 106. Les NVIDIA Tegra 186 et 194 bĂ©nĂ©ficient maintenant de l’audio via le port HDMI. Le Plan Alpha est intĂ©grĂ© aux Exynos. VMWGFX gĂšre maintenant la commutation de page (page flipping). Les Rockchips, MALI, Sun4Xi et Meson ne sont pas en reste.

Autres améliorations
  • gestion de la compression de flux dynamique DSC (dynamic stream compression) des gĂ©nĂ©rations 10 et 11 des displays ports et external display ports, selon la norme VESA DP 1.4 ;
  • prise en charge gĂ©nĂ©rique Ă  un Ă©quivalent Ă  ci‐dessus, pour le port HDMI — voir ce commit initial.

RĂ©seau

Pas moins de 36 pilotes reçoivent des correctifs et amĂ©liorations. Une vĂ©ritable tempĂȘte. On notera particuliĂšrement parmi ceux‐ci :

  • cĂŽtĂ© professionnel, les Mellanox gĂ©rĂ©es par mlx5 (carte ConnectX de 5e gĂ©nĂ©ration) reçoivent seize amĂ©liorations : GRE, tunnels au travers de VLAN tc, amĂ©liorations du DEVX et de ses commandes spĂ©cifiques, implĂ©mentation de l’IBTA CapabilityMask2, etc. — notons que la configuration de ces cartes est aisĂ©e avec le paquet mstflint et sa commande msfconfig ;
  • cĂŽtĂ© grand public, de nouvelles cartes sont dĂ©sormais gĂ©rĂ©es par iwlwifi : les 9461, 9462, 9560 et la sĂ©rie dite killer ; les Broadcom sont Ă©galement de la partie, avec pas moins de neuf amĂ©liorations recensĂ©es par votre serviteur, dont la 4354 pour le brcmfmac (dont il est souvent question de nos jours : c’est fait) ;
  • l’arrivĂ©e de l’autonĂ©gociation pour la 5G (et la 2,5G) pour le PHY.

Enfin, et ce n’est pas la moindre des amĂ©liorations, le protocole UDP reçoit le support du Generic Receive Offload (GRO), voir ce premier commit pour cette sĂ©rie. Le sujet est ancien et a connu semble‐t‐il plusieurs propositions correctives. Cela impacte les performances du protocole UDP, dans un contexte gĂ©nĂ©ral d’augmentation de la bande passante disponible et d’augmentation de la puissance processeur, avec une MTU par dĂ©faut ancestrale et/mais une PMTU ne fonctionne pas dans la plupart des cas pour cause de rĂ©ponse ICMP plus ou moins autorisĂ©e ou traitĂ©e, et oĂč la segmentation en paquets devient parfois et malgrĂ© tout un goulot d’étranglement. GRO semble supĂ©rieur au couple LSO‐LRO et est maintenant gĂ©rĂ© par de nombreuses cartes rĂ©seaux. ConcrĂštement, un ensemble de paquets UDP va traverser la pile en une seule unitĂ©, faisant ainsi une seule transaction pour l’espace utilisateur, et ceci sans modifier ni fusionner lesdits paquets UDP de l’ensemble.

SystĂšmes de fichiers

BinderFS

On note l’arrivĂ©e de BinderFS, un pseudo‐systĂšme de fichiers dĂ©diĂ© pour l’IPC « binder » d’Android.

Binder est un dispositif ancien dans Android, et depuis Android O (Oreo, en 2017) toute la communication avec la HAL (hardware abstraction layer) et le cadriciel Android se fait avec lui, et des amĂ©liorations importantes ont Ă©tĂ© apportĂ©es, notamment avec l’utilisation des entrĂ©es‐sorties vectorisĂ©es.

« Qui contrĂŽle l’IPC contrĂŽle le Droid ». Le problĂšme avec Binder est qu’il n’existe pas en tant que module pour le noyau vanilla (AOSP uniquement), d’une part, et d’autre part le nombre de devices disponibles est fixé  Ă  la compilation. L’objectif de BinderFS sur Linux est de permettre l’utilisation de Binder dans des espaces de noms d’IPC (IPC namespace), donc de pouvoir en avoir plusieurs en mĂȘme temps, isolĂ©s les uns des autres, et de permettre l’allocation dynamique du nombre de devices disponibles.

Pour mĂ©moire, IPC namespace a apportĂ© la capacitĂ© d’utiliser des IPC (communications inter‐processus) Ă  l’intĂ©rieur d’un espace de noms, donc de les isoler pour y proposer un nombre restreint et privĂ© d’objets IPC. Le cas typique d’usage est l’utilisation de conteneurs. Chaque nouvel espace de noms d’IPC va ici pouvoir monter une nouvelle instance de BinderFS, disposant donc de son propre dispositif de contrĂŽle Binder ! Avec tout ce que propose ce fameux /dev/binder-control, isolĂ© et sans limite fixĂ©e sur le nombre de devices. Il est ainsi possible de lancer plusieurs couches Android simultanĂ©ment, sur un mĂȘme noyau et vanilla. Sans couche de virtualisation, juste comme ça. « C’est fou ! » « Oui, mais vous aimez ».

Adiantum

Adiantum fait son apparition, il s’agit de chiffrement pour des appareils ne disposant pas des instructions AES (typiquement les tĂ©lĂ©phones que l’on trouve dans les pays dit Ă©mergents). C’est une bonne nouvelle pour nos amis là‐bas !

Btrfs

Btrfs dispose maintenant de la gestion de l’espace d’échange mĂ©moire (swap), et non ce n’est pas une blague.

CIFS/SMB

Du cĂŽtĂ© de CIFS, c’est l’arrivĂ©e du cache et du failover (basculement) pour le DFS (Distributed File System, systĂšme distribuĂ© de fichiers sous CIFS), permettant aux clients de se reconnecter de maniĂšre transparente Ă  un autre serveur CIFS, servant le ou les mĂȘmes montages, si le premier serveur utilisĂ© n’est plus disponible. Pour mĂ©moire, il s’agit d’une des deux fonctions essentielles apportĂ©es par DFS, avec le balancement de charges entre serveurs. Le DFS (cĂŽté Windows) propose en plus une tambouille de liens symboliques pour prĂ©senter Ă  l’exportation une autre racine que la racine rĂ©elle (rendant ainsi la vue cĂŽtĂ© client diffĂ©rente d’un client Ă  un autre si l’administrateur le veut). Et CIFS, dans ses attributs Ă©tendus (xattr), dispose (enfin ?) d’un assemblage (compound), permettant ainsi de rĂ©duire la charge rĂ©seau (diminution des aller‐retours d’informations : on embarque tout dans une seule requĂȘte de plus grande taille) et d’amĂ©liorer les performances CIFS pour ce point.

AutoFS

Un changement qui devrait avoir toute votre attention concernant AutoFS : le retour de l’option strictexpire. Elle rĂ©solvait un problĂšme lorsque les auto‐montages n’expirent pas, par exemple avec des accĂšs « agressifs » (comprendre : normaux) par les clients. Ce correctif a ensuite Ă©tĂ© retirĂ© car il entrainait, dans de larges environnements avec de nombreux clients, de nombreuses requĂȘtes inutiles de montage donc une charge importante pour le serveur (quand les clients Ă©taient laissĂ©s en configuration par dĂ©faut avec une valeur par dĂ©faut pour le temps sans accĂšs avant dĂ©montage). Ce correctif marque le retour de cette option.

Virtualisation

CÎté Virtualisation on notera entre autres :

  • l’arrivĂ©e de la fonction « Processor Trace » d’Intel dans KVM, pour ses machines virtuelles invitĂ©es ; la gestion d’IPT date de plusieurs annĂ©es et permet de tracer l’activitĂ© (d’une application, par exemple) sans surcoĂ»t pour les performances, elle est maintenant mise Ă  disposition pour la virtualisation ;
  • pas mal d’amĂ©liorations pour VirtIO :
    • prise en charge de la configuration du Large Receive Offload (LRO, approche similaire aux Jumbos Frames), l’ajout de la gestion du discard (trim) sur le pilote virtio_blk et l’activation lorsque le pĂ©riphĂ©rique dĂ©clare ces options,
    • l’ajout de la gestion l’EDID (petit binaire contenu dans chaque Ă©cran et envoyĂ© au systĂšme pour dĂ©clarer ses caractĂ©ristiques) pour le pilote virtio_gpu,
    • la modification du cĂŽtĂ© de la synchronisation avec un descripteur de fichier sync_file renvoyĂ© Ă  l’espace utilisateur, comprenant l’appel de fin de synchronisation reçu ;
  • l’ajout du « dirty log reprotect » pour KVM : l’idĂ©e semble ĂȘtre de libĂ©rer le verrou mmu_lock le plus tĂŽt possible, pour cela le get_dirty_log n’envoie plus de page protĂ©gĂ©e en Ă©criture, c’est l’espace utilisateur qui se charge de nettoyer avant usage des nouvelles infos prĂ©sentĂ©es.

Statistiques

Nous vous invitons simplement Ă  lire les informations collectĂ©es par Jonathan Corbet pour LWN.net pour la RC-7. L’Europe arrive largement en tĂȘte.

Autour du noyau

Du cĂŽtĂ© de la Fondation Linux, qui s’occupe de bien d’autres choses que du noyau, les nouvelles les plus rĂ©centes sont :

  • pas moins de 22 nouveaux membres rejoignent la Fondation ;
  • le Projet ELISA, Enabling Linux In SAfety critical systems, est lancé ; un effort commun (BMW, Toyota, Linutroniks et KUKA viennent de rejoindre le projet) afin de simplifier le dĂ©veloppement d’applications critiques (oĂč la vie humaine peut ĂȘtre en jeu) basĂ©es sur le noyau Linux ; le but n’est pas une nouveautĂ© en soi, il s’agit d’une nouvelle alliance ouverte ;
  • Automotive Grade Linux, autre alliance ouverte, publie une API pour la reconnaissance vocale ;
  • lancement de l’Academy Software Foundation par la Fondation Linux et l’« Academy of Motion Picture Arts and Sciences », comprenant entre autres Animal Logic, Autodesk, Blue Sky Studios, Cisco, DNEG, DreamWorks Animation, Epic Games, Foundry, Google Cloud, Intel, SideFX, The Walt Disney Studios, et Weta Digital. Que du beau monde ? ;-)

Pour terminer

Un nouvel utilitaire permet la production d’un fichier configure_commands au format JSON. À l‘instar de libtooling du projet Clang/LLVM et de ce que font des outils tels que CMake ou Bazel, cet utilitaire va chercher les <cibles>.o.cmd dans l’arborescence du noyau (contenant l’ensemble des informations nĂ©cessaires Ă  la compilation), en extrait ces commandes de compilation et produit un fichier en sortie unique compile_commands.json qui pourra ĂȘtre utilisĂ© Ă  loisir par tout outil basĂ© sur la libtooling. make config; make -j$(nproc); scripts/gen_compile_commands.py.

Aller plus loin

  • # Pilotes de cartes graphique

    Posté par  . Évalué à 7.

    Pilotes de cartes graphiques
    AMD et sa Radeon VII, semble bien ĂȘtre le meilleur choix pour les joueurs libristes et plus gĂ©nĂ©ralement de tous les joueurs sous Linux. Cette carte et son pilote libre amdgpu, accompagnĂ©e de Mesa, bat en performance une Nvidia RTX 2080.
    OK ? OK !

    Une petite question concernant l'extrait ci-dessus : est-ce que la comparaison est faite entre les drivers Open Source (amdgpu / nouveau) ou entre le driver Open Source amdgpu et le driver propriétaire nvidia ?

    • [^] # Re: Pilotes de cartes graphique

      Posté par  (Mastodon) . Évalué à 10. DerniĂšre modification le 04 mars 2019 Ă  21:27.

      Oui la comparaison est faite entre une rtx 2080 avec son pilote propriétaire et une radeon VII avec son pilote libre. Oui ! :-)

      [edit] pas dans toutes les situations : donc le verbe 'battre' remplacé par 'accrocher' à l'instant. Les performances du pilote libre sont tellement scotchantes qu'elles sont enivrantes. Et ajout de la précision de contexte : libre amd VS proprio nvidia. Merci !

      • [^] # Re: Pilotes de cartes graphique

        Posté par  (site web personnel) . Évalué à 1. DerniĂšre modification le 04 mars 2019 Ă  21:43.

        Reste maintenant Ă  choper une carte, il parait qu'il n'y aura que seulement 5000 heureux vu qu'il parait que pour arriver Ă  Ă©galer le prix d'une nVidia 2080, AMD perd de l'argent (faut dire que balancer 16 GB de RAM, ça doit pas ĂȘtre donnĂ©, quelle idĂ©e
) + la conso Ă©lectrique semble plus Ă©levĂ©e (~300 contre ~200 W Ă  plein rĂ©gime).

        Bref, potentiellement accrocheur si il n'y a pas bidouille pour avoir un prix du libre Ă©gal au prix de proprio Ă  performance Ă©quivalente, sinon combien seriez-vous prĂȘt Ă  mettre en plus Ă  performance Ă©gale pour un pilote libre?

        • [^] # Re: Pilotes de cartes graphique

          Posté par  . Évalué à 4.

          Clairement, vu la conception à base de HBM et la possibilité de faire du calcul en demi-précision (FP16), les cartes d'architecture Vega ne sont pas conçues pour le jeu mais pour le GPGPU.
          C'est l'une des raisons de la différence de ratio performance/W en jeu face aux cartes moyen-haut de gamme Nvidia de série 1000 et 2000.

          AprÚs ce sont des cartes bien plus faciles à bidouiller pour de l'overclocking par rapport aux cartes Nvidia Pascal et Turing : la conception de l'étage d'alimentation et de sa régulation sont beaucoup plus simples et moins contraignantes.

        • [^] # Re: Pilotes de cartes graphique

          Posté par  (site web personnel) . Évalué à 10.

          300W ?
          Mais moi j'ai juste besoin d'un framebuffer hein :D

        • [^] # Re: Pilotes de cartes graphique

          Posté par  (site web personnel) . Évalué à 10. DerniĂšre modification le 05 mars 2019 Ă  17:05.

          Je mettrais un truc comme 100€ de plus pour ne pas avoir de soucis avec le drivers 3D et des performances.

          Je reste sur du pure Intel pour éviter les ennuis. J'ai eu tellement de soucis avec des trucs 3D qui plantent la machine complÚtement, les recompilations de module, ou les "accélérations" vidéo qui finissent en écran noir et autre, la retour de veille qui plante, le ventilo tout le temps à fond, la non gestion des 2 cartes présentes Intel/X, que je me méfie beaucoup. De plus, je n'ai aucunes idées des cartes qui sont actuellement un peu correctement supporté ou pas (en dehors de intel).

          C'est dommage, car beaucoup de soft libre pourraient bénéficier des accélérations GPU (traitement d'image, browser, calcul scientifique
).

          "La premiÚre sécurité est la liberté"

          • [^] # Re: Pilotes de cartes graphique

            Posté par  . Évalué à 6.

            Je reste sur du pure Intel pour Ă©viter les ennuis.

            Depuis quelques mois je teste le iGPU d'un Pentium G4560 et j'ai un plantage OOM systĂ©matiquement aprĂšs le visionnage de quelques grosses vidĂ©os dans Firefox. Certes c'est pas la faute de Intel vu que c'est un problĂšme que je ne rencontre qu'avec Firefox (et vu les commentaire en dessous sur OOMkiller c'est commun) mais ce bug ne m'arrive pas en installant sur ce mĂȘme matĂ©riel une carte graphique qui possĂšde sa mĂ©moire dĂ©diĂ©e.

            De plus, je n'ai aucunes idées des cartes qui sont actuellement un peu correctement supporté ou pas (en dehors de intel).

            Chez AMD, les cartes d'architecture Polaris (sĂ©ries Radeon RX400 et 500) sont trĂšs trĂšs bien supportĂ©es et c'est leur entrĂ©e-milieu de gamme. Les cartes Vega aussi apparemment. Par contre aucune idĂ©e pour leur gamme d'APU mais je suppose qu'il y aura le mĂȘme problĂšme de mĂ©moire que je rencontre avec FF sur les iGPU Intel.

            Chez Nvidia, les cartes d'architecture Fermi et Kepler sont aussi hyper stables avec nouveau. Aucune idée pour les archi plus récentes mais le pilote ne supporte pas le frequency scalling et ces cartes restent à leur fréquence de base.
            Sinon c'est con mais perso le pilote proprio de Nvidia ne m'a jamais posé de problÚmes hormis l'installation un peu pénible parfois.

            • [^] # Re: Pilotes de cartes graphique

              Posté par  (site web personnel) . Évalué à 2.

              La veille fonctionne ? Quand est-il des versions portables ? Et des versions intégrés avec le gpu AMD ? Est-ce que la bascule gpu intel / carte externe fonctionne ? Est-ce que le ventilo sont géré ou tout le temps à fond ?

              "La premiÚre sécurité est la liberté"

              • [^] # Re: Pilotes de cartes graphique

                Posté par  . Évalué à 6.

                J'ai une rx580 (polaris), avec le pilote libre amdgpu.
                En veille la carte consomme un peu plus de 30w, le frequency scaling fonctionne trĂšs bien, tu peux mĂȘme le gĂ©rer par toi mĂȘme en fixant les paliers, la vitesse des ventilos est aussi gĂ©rable manuellement (echo 1 dans /sys/class/drm/card0/device/hwmon/hwmon0/pwm1_enable puis tu fixe la vitesse dans /sys/class/drm/card0/device/hwmon/hwmon0/pwm1), je me suis fait un script bash qui rĂ©gule leur vitesse en fonction de la charge de la carte et de sa tempĂ©rature.
                Il est possible (et recommandé) d'abaisser sa tension de fonctionnement, la carte chauffe et consomme beaucoup moins.

                Enfin concernant ses performances, rien Ă  dire pour mes besoins c'est parfait. Tu trouveras plein de graphs et de benchs sur phoronix.
                On trouve cette carte à 200 euros neuve environ, et si tu attends un peu la sortie de la nouvelle gen d'amd (navi), ça sera encore moins cher j'imagine.

                • [^] # Re: Pilotes de cartes graphique

                  Posté par  . Évalué à 3.

                  ça m'intéresse ! j'ai une rx480, peu bruyante et qui ne chauffe pas spécialement, mais je suis preneur du script, s'il y a moyen de le récupérer.

              • [^] # Re: Pilotes de cartes graphique

                Posté par  (site web personnel) . Évalué à -1.

                J'ai une MSI vega rx 64 depuis sa sortie sur un FX8370E. J'ai du attendre que le pilote soit inclus par défaut dans le noyau pour que ça marche directement sur ma Mageia, soit kernel linux 4.15 de mémoire.

                Au niveau bruit, tout ça je sais pas trop, j'ai collĂ© un watercooling dessus (D5/360). Sous linux ça chauffe jamais vraiment, la pompe et les ventilateurs en pwm restent au minimum mĂȘme en regardant des vidĂ©os sur smplayer/chrome. Idem en code.

                Faudrait que je teste la montée en température quand X4 foundations sera disponible.

                Sous plateforme propriétaire ça change, en jeu un peu de cold noise des condensateurs céramique qui vibrent et ça se transforme en bon chauffage sur le jeu.

                Jamais eu vraiment de bugs majeurs, trĂšs content de cette carte sous linux.

                Avant j'avais eu une 6870, ça avait marché directement quand je l'ai eu. Au début il y avait un script de phoronix pour patcher le binaire pour enlever un tatouage "carte non supportée" sur le rendu à l'écran. Tout marchait parfaitement en dehors de ça.

                Bref, aucun regret de fendre la tirelire pour prendre des cartes graphiques et processeurs chez amd qui a vraiment fait l'effort de faire marcher leurs produits sous linux avec du driver libre !

                • [^] # Re: Pilotes de cartes graphique

                  Posté par  . Évalué à 3.

                  Sous plateforme propriétaire ça change, en jeu un peu de cold noise des condensateurs céramique qui vibrent et ça se transforme en bon chauffage sur le jeu.

                  Ce n'est pas du tout une question de condensateurs et ça n'a pas vraiment d'incidence sur les pertes joules.
                  Le coil whine est dĂ» aux inductances des VRM. C'est le mĂȘme phĂ©nomĂšne de rĂ©sonnance que lorsqu'une alimentation bourdonne (d'oĂč des bobines noyĂ©es dans la cire ou la colle pour contrer cet effet) sauf que les inductances utilisĂ©es sur les cartes graphiques ont un design particulier (ayant un trĂšs fort courant max, une faible rĂ©sistance et le tout dans un petit boitier) qui malheureusement favorise cette vibration.

        • [^] # Re: Pilotes de cartes graphique

          Posté par  (Mastodon) . Évalué à 4.

          5000 heureux

          Ah ouhé ? Cette info ne doit dĂ©jĂ  plus ĂȘtre Ă  jour car les livraisons des diffĂ©rents vendeurs sont disponibles, les tarifs vont de 750 Ă  850€ TVA inclue. Dans toutes les boutiques : elles sont disponibles, et aux prix annoncĂ©s.

  • # OuĂ©, du BeOS dans Linux \o/

    Posté par  (site web personnel) . Évalué à 10.

    OuĂ©, parce que le Binder vient de BeOS, mĂȘme s'il a trĂšs peu Ă©tĂ© utilisĂ©, c'Ă©tait une expĂ©rimentation assez tardive :
    https://en.wikipedia.org/wiki/OpenBinder

  • # 2.0.34 mon premier kernel - et chromebook

    Posté par  . Évalué à 6.

    Que de chemin parcouru depuis mon premier 2.0.34 sur la mandrake 5.1
 \o/

    Bon, sinon, sur mon chromebook asus C301, c'est toujours un 4.15 qui tourne alors mĂȘme que les kernels suivant ont promis des amĂ©liorations notables pour ces configurations type Terra.
    Impossible de booter autre chose que le kernel tuné de chez GalliumOS, distribution aujourd'hui figée depuis 18 mois faut de dev disponible.

    Longue vie Ă  ce kernel 5! (et merci pour la dĂ©pĂȘche, trĂšs intĂ©ressante comme toujours).

    • [^] # Re: 2.0.34 mon premier kernel - et chromebook

      Posté par  . Évalué à 4.

      mon mien boote avec d'autres distribs, mais le gros problĂšme c'est le clavier qui n'est pas supportĂ©, mĂȘme aprĂšs quelques modifs rĂ©alisĂ©es Ă  l'aide d'un clavier usb :-(
      au passage, le clavier fonctionne encore sans problùme avec Grub juste avant le chargement du kernel
 ;-)
      elementaryOS fonctionne aussi out-of-box, et elle continue de tourner dessus comme un charme :-)

      cÎté kernel, c'est vrai, beaucoup de chemin parcouru et beaucoup de bon travail abattu : merci à tous ceux qui y contribuent de prÚs comme de loin !

      et comme d'hab, belle dĂ©pĂȘche : merci !

  • # Du cĂŽtĂ© des RISC-V le support pour l'audit est lĂ .

    Posté par  (site web personnel, Mastodon) . Évalué à 7. DerniĂšre modification le 05 mars 2019 Ă  09:08.

    Du cÎté des RISC le support pour l'audit est là.

    RISC est juste un type d'architecture de processeur, une philosophie consistant à réduire le nombre d'instructions et à les simplifier. ARM et MIPS sont des RISC par exemple.

    Par contre Risc-V (nommé riscv dans le kernel, se prononce risque failleve) est un nouveau jeux d'instructions de type RISC qui est désormais disponible dans le noyau Linux et supporté officiellement.

    Risc-V est la révolution libre des processeurs ;)

    J'ai plus qu'une balle

  • # Comment fonctionne "OOM Killer" et la gestion de la saturation du processeur et de la mĂ©moire ?

    Posté par  (site web personnel) . Évalué à 10.

    Je me demande bien comment fonctionne la gestion des processus qui saturent le processeur ou la mĂ©moire. De mon cĂŽtĂ©, il ne met jamais arrivĂ© qu'un processus qui sature mon processeur ou ma mĂ©moire soit tuĂ© par mon systĂšme d'exploitation. Alors que cela m'arrive rĂ©guliĂšrement depuis des annĂ©es. Par exemple, il arrive que certaines pages fassent que Firefox rĂ©clame tout mon CPU et ma mĂ©moire. Au bout d'un moment, mon ordinateur se bloque et n'est plus utilisable. MĂȘme en attendant des heures (et ça ne doit vraiment pas ĂȘtre bon pour le processeur vu comment il mouline
), le processus n'est pas tuĂ© par Linux. J'imagine qu'il s'agit d'un combo de bugs: Firefox qui ne gĂšre pas correctement un jeu en HTML5 et Linux qui ne parvient pas Ă  tuer un processus.

    Est-ce qu'il y a quelque chose à faire pour faire en sorte que Linux tue plus facilement le ou les processus liés à Firefox ? (sur une Fedora 29 si cela a de l'importance)

    • [^] # Re: Comment fonctionne "OOM Killer" et la gestion de la saturation du processeur et de la mĂ©moire ?

      Posté par  . Évalué à 4.

      Tu as de la swap ?

    • [^] # Re: Comment fonctionne "OOM Killer" et la gestion de la saturation du processeur et de la mĂ©moire ?

      Posté par  (site web personnel) . Évalué à 9. DerniĂšre modification le 05 mars 2019 Ă  18:28.

      OOM killer entre en action quand un processus essaie d'allouer de la mémoire mais qu'il n'y en a plus de disponible (en gros). C'est uniquement lié à la gestion de la mémoire. Donc si tu as un processus qui utilise tout ton CPU en permanence aucun mécanisme n'existe pour le tuer.
      C'est logique d'ailleurs car il y a tout un tas d'application ou un processus va toujours utiliser beaucoup de temps processeur, par exemple sur un serveur chargé, une station de calcul, quelqu'un qui mine de la cryptomonnaie, etc.
      Pour empĂȘcher qu'un processus utilise en permanence tout le temps processeur sur ta machine tu peux essayer de jouer avec les cgroups pour limiter l'effet.

      • [^] # Re: Comment fonctionne "OOM Killer" et la gestion de la saturation du processeur et de la mĂ©moire ?

        Posté par  . Évalué à 8.

        Donc si tu as un processus qui utilise tout ton CPU en permanence aucun mécanisme n'existe pour le tuer.

        Quand on a que ce problĂšme-lĂ , on ne perd pas la main.

        Quand on n’arrive plus Ă  reprendre la main sur le systĂšme, c’est parce qu’il swappe Ă  mort. J’ai parfois le mĂȘme cas que lejocelyn sur une bĂ©cane qui n’a que 4 Go.

        Il fut pourtant un temps oĂč ça ne faisait pas ça. Je me demande si c’est Linux qui gĂšre moins bien le coup, ou les conditions qui se sont dĂ©gradĂ©es : un seul processus, celui du navigateur (quel qu’il soit ; j’ai essayĂ© avec plusieurs, quand certaines pages pourries font exploser leur consommation de ressources, j’en arrive toujours Ă  la mĂȘme situation), qui bouffe plus que la mĂ©moire physique Ă  lui tout seul, alors qu’à l’époque, c’était seulement l’ensemble des processus qui dĂ©passait.

        J’ai essayĂ© plus ou moins de swap, sans rĂ©ussir Ă  Ă©viter complĂštement la situation (mieux vaut quand mĂȘme qu’il n’y en ait pas trop, mais si on veut pouvoir mettre le systĂšme en hibernation, il en faut malheureusement au moins autant que de mĂ©moire physique).
        MĂȘme sans swap du tout, comme le fait remarquer Chris Down au point 6 dans le lien postĂ© plus haut par kna, le manque de buffer fait Ă©crouler les performances en Ă©criture de fichiers et la situation est similaire. Tout au plus le manque de mĂ©moire dĂ©clenche-t-il l’OOM killer plus tĂŽt.

        J’ai bien trouvĂ© une solution pour Ă©viter cette situation : lancer le navigateur avec ulimit -v une taille plus petite que la mĂ©moire physique (genre ulimit -v 3000000 firefox &), mais ça se traduit, au moins pour Firefox, par un plantage trĂšs sale quand il n’a plus de mĂ©moire. Pas idĂ©al si l’on est en train de faire quelque chose d’important avec (et comme il y a de plus en plus de choses qu’on fait sur le web)


        « Le fascisme c’est la gangrĂšne, Ă  Santiago comme Ă  Paris. » — Renaud, Hexagone

        • [^] # Re: Comment fonctionne "OOM Killer" et la gestion de la saturation du processeur et de la mĂ©moire ?

          Posté par  . Évalué à 3.

          Quand on n’arrive plus Ă  reprendre la main sur le systĂšme, c’est parce qu’il swappe Ă  mort. J’ai parfois le mĂȘme cas que lejocelyn sur une bĂ©cane qui n’a que 4 Go.

          J'ai une machine qui n'a que 2Gio de DDR2 et je n'ai jamais eu ce comportement. Ce n'est pas toujours confort, surtout quand on a l'habitude de machine qui ont 16Gio. J'ai rien configurĂ© de particulier. Juste pour que ce soit plus confortable j'ai arrĂȘtĂ© d'utiliser un webmail au profit d'un MUA natif, mais mĂȘme sans ça je n'ai pas eu de plantage comme vous en parlez.

          Vous avez passĂ© un coup de memcheck quelques heures pour vĂ©rifier qu'il n'y a pas de problĂšme matĂ©riel ?

          • [^] # Re: Comment fonctionne "OOM Killer" et la gestion de la saturation du processeur et de la mĂ©moire ?

            Posté par  . Évalué à 5.

            J’ai pas mal d’onglets ouverts, genre plus de 70 avec chromium, qui n’est pas mon navigateur principal (l’extension Lazy Tabs Ă©vite qu’il consomme directement la mĂ©moire Ă  lui tout seul), beaucoup plus avec Firefox (configurĂ© aussi pour ne pas charger les onglets avant qu’on y accĂšde ; pas besoin d’extension, c’est dans les prĂ©fĂ©rences). MĂȘme sans que les onglets soient chargĂ©s, ça fait une certaine consommation Ă  la base. J’ai aussi Thunderbird qui consomme une bonne quantitĂ© de mĂ©moire, du fait de pas mal de comptes et de mails dedans. À certains moments, il monte beaucoup en consommation, avant de se dĂ©cider Ă  redescendre Ă  un niveau plus raisonnable au bout d’un certain temps (je suppose qu’il lance un garbage collector).

            Le problĂšme arrive si j’ai le malheur de charger en mĂȘme temps plus de trois ou quatre pages/applications qui consomment beaucoup de mĂ©moire et augmentent constamment leur consommation, du genre de Google Street View, ou pire une ou deux comme ça et un site complĂštement boguĂ©, dont un script a manifestement une fuite mĂ©moire colossale (s’il ne bouffait que du CPU, on pourrait encore soupçonner qu’il fait du minage de cryptomonnaie, mais avec une consommation mĂ©moire dĂ©lirante, ce serait se tirer une balle dans le pied). Parce que dans le premier cas, quand la consommation mĂ©moire n’augmente pas trop vite, je vois Ă  la jauge mĂ©moire que je me dirige vers un problĂšme et je relance le navigateur avant (Ă  une Ă©poque, j’utilisais une extension pour dĂ©charger les onglets sur Firefox, mais elle ne fonctionne plus et je n’en ai pas encore cherchĂ© d’autre ; qui plus est, mĂȘme quand on ferme carrĂ©ment des onglets qui consomment beaucoup, Firefox ne rend pas forcĂ©ment la mĂ©moire pour autant). Mais quand c’est trop rapide, je n’ai pas forcĂ©ment le temps. Souvent les scripts contenus dans les pages web sont d’une « qualité » qu’on n’accepterait pas pour un logiciel natif.

            Noscript Ă©vite que ça m’arrive souvent, mais il arrive vraiment que je veuille voir certaines pages qui n’affichent rien sans autoriser les scripts, et parfois une mauvaise conjonction de pages lourdes ou pourries fait partir le navigateur complĂštement en sucette.

            « Le fascisme c’est la gangrĂšne, Ă  Santiago comme Ă  Paris. » — Renaud, Hexagone

            • [^] # Re: Comment fonctionne "OOM Killer" et la gestion de la saturation du processeur et de la mĂ©moire ?

              Posté par  . Évalué à 3.

              J’ai pas mal d’onglets ouverts, genre plus de 70 avec chromium, qui n’est pas mon navigateur principal (l’extension Lazy Tabs Ă©vite qu’il consomme directement la mĂ©moire Ă  lui tout seul), beaucoup plus avec Firefox (configurĂ© aussi pour ne pas charger les onglets avant qu’on y accĂšde ; pas besoin d’extension, c’est dans les prĂ©fĂ©rences).

              C'est Ă©norme
 Le fait que les navigateurs se dĂ©coupent maintenant en thread systĂšme doit aider, mais c'est pas magique non plus. Linux ne peux pas beaucoup t'aider tel quel. Mais je pense que si tu utilise diffĂ©rentes instances de navigateurs pour sĂ©parer tes onglets les plus lourds linux pourra avoir un meilleur scheduling et mieux sĂ©parer les ressources. L'Ă©tape suivante, si nĂ©cessaire, Ă©tant de lancer ces instances dans des cgroups distincts. Ça n'est pas forcĂ©ment trĂšs compliquĂ©, mais tu peux probablement fortement amĂ©liorer l'utilisabilitĂ© de ton installation.

            • [^] # Re: Comment fonctionne "OOM Killer" et la gestion de la saturation du processeur et de la mĂ©moire ?

              Posté par  . Évalué à -1. DerniĂšre modification le 06 mars 2019 Ă  16:12.

              "J'ai 70 onglets, mais c'est la faute au swap / Ă  linux / au kernel / Ă  l'OOM Killer."

              Euhhh
 Comment dire


              "Quand certains rĂąlent contre systemd, d'autres s'attaquent aux vrais problĂšmes." (merci Sinma !)

              • [^] # Re: Comment fonctionne "OOM Killer" et la gestion de la saturation du processeur et de la mĂ©moire ?

                Posté par  . Évalué à 2.

                Ils ne sont pas tous chargĂ©s. Et je ne m’étonne pas de la mĂ©moire que ça consomme.

                Mais il fut une Ă©poque oĂč quand la machine commençait Ă  trop swapper, on avait encore suffisamment la main pour fermer une ou deux applications, ça ne s’écroulait pas d’un coup.

                Mais c’est peut-ĂȘtre dĂ» Ă  la nature des applications : un certain nombre d’onglets qui turbinent Ă  fond accĂšdent sĂ»rement plus Ă  leur mĂ©moire qu’un traitement de texte dans lequel tu as chargĂ© un trĂšs gros document : quand tu travailles sur la fin, il n’a pas besoin d’accĂ©der au dĂ©but, donc s’il est dans le swap, ça aura peu d’impact.

                Ou peut-ĂȘtre Ă  l’augmentation des tailles mĂ©moires en jeu par rapport au temps d’accĂšs au disque dur qui n’a pas autant progressĂ©. C’est sĂ»r que le swap fonctionne certainement mieux sur un SSD, si ce n’est que ça n’arrangera pas le SSD Ă  terme.

                « Le fascisme c’est la gangrĂšne, Ă  Santiago comme Ă  Paris. » — Renaud, Hexagone

                • [^] # Re: Comment fonctionne "OOM Killer" et la gestion de la saturation du processeur et de la mĂ©moire ?

                  Posté par  . Évalué à 4.

                  J'ai eu exactement le mĂȘme soucis, j'ai postĂ© 1 ou 2 fois ici et sur le forum on m'avait conseillĂ© limits.conf et les cgroups. J'avoue n'avoir pas testĂ© car depuis j'ai pris une simple habitude : je ferme le navigateur Ă  la fin de la journĂ©e. Le lendemain je le rouvre et il ne charge que le 1er onglet de chaque fenĂȘtre donc la consommation reste acceptable.

                  On m'a aussi fait comprendre que mes onglets utilisaient une quantité de RAM "délirante" (Firefox + Thunderbird me bouffent 6 sur 8go) mais à ce niveau je n'ai pas vraiment de moyen d'action


                  Et comme toi je fais le constat que ce problÚme est relativement récent. 1 ou 2 ans grand maximum, pourtant j'ai toujours eu des dizaines d'onglets ouverts. Donc soit le web est devenu ingérable à cause des des frameworks JS front, soit y'a un soucis dans Firefox, ou le noyau, ou les trois


                  • [^] # Re: Comment fonctionne "OOM Killer" et la gestion de la saturation du processeur et de la mĂ©moire ?

                    Posté par  . Évalué à 5.

                    Du cĂŽtĂ© de Chromium, autant en standard il est calamiteux en chargeant tous les onglets, autant il devient bien plus intĂ©ressant avec l’extension Lazy Tabs :
                    – il ne charge plus tous les onglets immĂ©diatement, mais seulement quand on les clique ;
                    – quand on clique sur l’icĂŽne, cela dĂ©charge les autres onglets que le courant.

                    Quand on a ouvert par exemple des services Google, comme Google Maps ou Youtube, dĂ©charger leurs onglets libĂšre instantanĂ©ment une grosse quantitĂ© de mĂ©moire (ce qui n’est pas forcĂ©ment le cas avec Firefox, soit qu’il tarde Ă  faire passer son garbage collector, soit qu’il prĂ©fĂšre conserver la mĂ©moire dans la perspective de la rĂ©utiliser plus tard).

                    Je ne dis pas cependant que Chromium consomme moins que Firefox Ă  utilisation identique. Je ne peux mĂȘme pas en avoir une utilisation identique : aprĂšs un certain nombre d’onglets (atteint plus vite sur l’écran de mon portable du fait de sa faible dĂ©finition), les onglets les plus Ă  droite ne sont plus visibles


                    Et comme toi je fais le constat que ce problÚme est relativement récent. 1 ou 2 ans grand maximum, pourtant j'ai toujours eu des dizaines d'onglets ouverts. Donc soit le web est devenu ingérable à cause des des frameworks JS front, soit y'a un soucis dans Firefox, ou le noyau, ou les trois


                    Pour les navigateurs, la consommation mĂ©moire est clairement liĂ©e aux sites. En termes de charge mĂ©moire comme CPU, Google Maps, par exemple, est vraiment beaucoup plus lourd que les anciennes versions. Le mot qui m’est venu Ă  l’esprit lors de son changement de version le plus marquant a Ă©tĂ© « sabotage ». Fermer ou dĂ©charger les onglets de ce genre de sites sous Chromium permet bien de se rendre compte de leur consommation mĂ©moire.

                    Pour le fait que quand on a atteint la limite de la mĂ©moire physique, le systĂšme s’écroule d’un coup au lieu de juste se ralentir et qu’on ait encore suffisamment la main pour fermer sereinement des applications, j’aimerais bien avoir l’explication


                    « Le fascisme c’est la gangrĂšne, Ă  Santiago comme Ă  Paris. » — Renaud, Hexagone

          • [^] # Re: Comment fonctionne "OOM Killer" et la gestion de la saturation du processeur et de la mĂ©moire ?

            Posté par  (site web personnel) . Évalué à 1.

            Merci pour ces réponses, ça éclaire un peu ma petite lanterne :)

            En ce qui concerne memcheck, oui c'est fait, et il ne détecte pas de problÚme.

            Je vais essayer la combinaison de touches Magic SysRq proposer par Arthur Accroc plus bas.

    • [^] # Magic SysRq

      Posté par  . Évalué à 7.

      Il y a une combinaison de touches pour dĂ©clencher l’OOM Killer : Alt+SysRq+f
 Ă  condition que la prise en charge de ces combinaisons ne soit pas dĂ©sactivĂ©e, ce qui est souvent le cas par dĂ©faut (voir le lien prĂ©cĂ©dent pour l’activer).

      Il fut une Ă©poque oĂč ça marchait Ă  tous les coups pour moi dans un cas semblable : il supprimait toujours le navigateur du premier coup (si j’avais un autre logiciel qui partait en sucette comme le navigateur Ă  cause de certaines pages pourries, je ne le garderais pas).

      Les derniĂšres fois, ça n’a pas eu trop l’air de fonctionner, je ne sais pas si c’est parce que ça s’est encore dĂ©sactivĂ© ou parce que l’algorithme prĂ©fĂšre maintenant supprimer des processus peut-ĂȘtre moins utilisĂ©s, mais pas Ă  l’origine du problĂšme.

      « Le fascisme c’est la gangrĂšne, Ă  Santiago comme Ă  Paris. » — Renaud, Hexagone

      • [^] # Re: Magic SysRq

        Posté par  . Évalué à 2.

        J’ai le mĂȘme soucis que dĂ©crit ici : parfois Firefox consomme tellement que le systĂšme devient inutilisable et il n’y a plus qu’à reboot (et je n’ai pas de swap).

        Un truc que j’ai remarquĂ© depuis quelque semaines c’est que l’OMM killer va parfois tuer le process WebExtension de Firefox. Parfois ça rĂ©sout le soucis de freeze du laptop, mais Firefox est inutilisable (tu peux mĂȘme plus le Ctrl-Q).

        • [^] # Re: Magic SysRq

          Posté par  (site web personnel) . Évalué à 3.

          j'ai 32 gig de ram sur mon laptop et ça arrive que firefox freeze
 je suis obligĂ© de le tuer
 je vĂ©rifierais la prochaine fois si c'est Ă  cause de la ram.

          www.solutions-norenda.com

          • [^] # Re: Magic SysRq

            Posté par  . Évalué à 1.

            Bizarre, j'ai Firefox ouvert en permanence avec une dizaine d'onglets sur une machine que je n'arrĂȘte quasiment jamais (en gros arrĂȘt seulement quand y a une mise Ă  jour kernel) et FF consomme seulement 400/500 Mo et je n'ai jamais eu de freeze 


  • # 5.0.1

    Posté par  (Mastodon) . Évalué à 4.

    Hello,

    Une version mineure, la 5.0.1, a été publiée ce matin. Elle inclut une cinquantaine de correctifs, dont celui-ci, le premier sur la liste du changelog : «une fuite de mémoire dans kernel_read_file», ainsi que des correctifs pour le bluetooth, des patch pour EroFS (SystÚme de Fichier en lecture seule avec des possibilités de compression/décompression, plutÎt dédié à Android). En bref, on télécharge ce 5.0.1

Suivre le flux des commentaires

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