Sortie du noyau Linux 5.0

Posté par bubar🦥 (Mastodon) le 04 mars 2019 à 18:35. Édité par Julien Jorge, palm123, Davy Defaud et Benoît Sibaud. Modéré par Ontologia. Licence CC By‑SA.

Étiquettes :

mar.

2019

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
Annonces des versions candidates par Linus Torvalds
- RC-1
- RC-2
- RC-3
- RC-4
- RC-5
- RC-6
- RC-7
- RC-8
Les nouveautés
Statistiques
Autour du noyau
Pour terminer

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 5^e 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 Ghorin le 04 mars 2019 à 21:11. É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 bubar🦥 (Mastodon) le 04 mars 2019 à 21:14. É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 Zenitram (site web personnel) le 04 mars 2019 à 21:39. É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 Anonyme le 04 mars 2019 à 23:01. É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 Francois Revol (site web personnel) le 04 mars 2019 à 23:02. Évalué à 10.
      
      300W ?
      Mais moi j'ai juste besoin d'un framebuffer hein :D
    - [^] # Re: Pilotes de cartes graphique
      
      Posté par Nicolas Boulay (site web personnel) le 05 mars 2019 à 17:05. É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 Anonyme le 05 mars 2019 à 18:36. É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 Nicolas Boulay (site web personnel) le 06 mars 2019 à 08:47. É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 ekyo le 06 mars 2019 à 10:39. É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 Ant le 06 mars 2019 à 22:13. É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 Raphaël G. (site web personnel) le 21 mars 2019 à 18:11. É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 Anonyme le 21 mars 2019 à 22:38. É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 bubar🦥 (Mastodon) le 23 mars 2019 à 00:33. É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 Francois Revol (site web personnel) le 04 mars 2019 à 22:16. É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 toctoc1 le 05 mars 2019 à 08:44. É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 Pyscal le 06 mars 2019 à 09:11. É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 martoni (site web personnel, Mastodon) le 05 mars 2019 à 09:06. É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
- [^] # Re: Du côté des RISC-V le support pour l'audit est là.
  
  Posté par martoni (site web personnel, Mastodon) le 05 mars 2019 à 14:26. Évalué à 2. Dernière modification le 05 mars 2019 à 14:26.
  
  Du coup si un admin peut corriger la dépêche ça serait sympa.
  
  J'ai plus qu'une balle
  - [^] # Re: Du côté des RISC-V le support pour l'audit est là.
    
    Posté par bubar🦥 (Mastodon) le 05 mars 2019 à 17:51. Évalué à 6. Dernière modification le 05 mars 2019 à 18:09.
    
    Bien conscient d'avoir laissé de côté cette arch dans la dépêche. Merci pour ta remarque c'est pris en compte pour la prochaine d'en parler plus.
    Ps : V ajouté.
    - [^] # Re: Du côté des RISC-V le support pour l'audit est là.
      
      Posté par Anonyme le 05 mars 2019 à 18:49. Évalué à 7.
      
      Tant qu'à faire, on pourrait aussi parler un peu plus de MIPS qui en réaction à l'engouement pour RISC-V a décidé de libérer son architecture.
      
      C'est un peu plus intelligent que la réaction désespérée d'ARM Holdings avec leur site web de désinformation qui a tenu trois jours après le tollé médiatique.
# Comment fonctionne "OOM Killer" et la gestion de la saturation du processeur et de la mémoire ?

Posté par lejocelyn (site web personnel) le 05 mars 2019 à 11:00. É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 MTux le 05 mars 2019 à 13:13. É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 lejocelyn (site web personnel) le 05 mars 2019 à 14:17. Évalué à 1.
    
    Oui.
    - [^] # Re: Comment fonctionne "OOM Killer" et la gestion de la saturation du processeur et de la mémoire ?
      
      Posté par Aris Adamantiadis (site web personnel) le 05 mars 2019 à 16:10. Évalué à 6.
      
      La swap a tendance à aggraver le problème, parce que le noyau fera tout ce qu'il peut pour éviter de tuer un process, quitte à rendre le système inutilisable tellement il swappe. Par principe je n'active de la swap que si je sais qu'une tâche particulière nécessite plus de ram virtuelle que ce qu'en possède la machine (par ex vieux laptops ou machines virtuelles low cost).
      - [^] # Re: Comment fonctionne "OOM Killer" et la gestion de la saturation du processeur et de la mémoire ?
        
        Posté par kna le 05 mars 2019 à 17:42. Évalué à 10.
        
        C'est pas si simple : https://chrisdown.name/2018/01/02/in-defence-of-swap.html
- [^] # Re: Comment fonctionne "OOM Killer" et la gestion de la saturation du processeur et de la mémoire ?
  
  Posté par paulez (site web personnel) le 05 mars 2019 à 18:28. É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 Arthur Accroc le 06 mars 2019 à 01:15. É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 barmic le 06 mars 2019 à 08:33. É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 Arthur Accroc le 06 mars 2019 à 09:57. É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 barmic le 06 mars 2019 à 10:53. É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 xcomcmdr le 06 mars 2019 à 16:10. É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 Arthur Accroc le 06 mars 2019 à 16:34. É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 Faya le 21 mars 2019 à 20:58. É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 Arthur Accroc le 22 mars 2019 à 05:57. É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 lejocelyn (site web personnel) le 06 mars 2019 à 09:59. É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 Arthur Accroc le 06 mars 2019 à 00:44. É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 Anonyme le 06 mars 2019 à 23:19. É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 collinm (site web personnel) le 07 mars 2019 à 14:32. É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 gpe le 29 mars 2019 à 15:55. É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 bubar🦥 (Mastodon) le 10 mars 2019 à 08:31. É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.