12.3. Changements notables dans le noyau
Le noyau de 64k pages
En plus du noyau RHEL 9 for ARM qui prend en charge 4k pages, Red Hat propose désormais un paquetage de noyau optionnel qui prend en charge 64k pages : kernel-64k.
Le noyau de taille de page 64k est une option utile pour les grands ensembles de données sur les plates-formes ARM. Il permet d'améliorer les performances de certains types d'opérations gourmandes en mémoire et en ressources processeur.
Vous devez choisir la taille de la page sur les systèmes à architecture ARM 64 bits au moment de l'installation. Vous pouvez installer kernel-64k uniquement par Kickstart en ajoutant le paquet kernel-64k à la liste des paquets dans le fichier Kickstart.
Pour plus d'informations sur l'installation de kernel-64k, voir Effectuer une installation avancée de RHEL 9.
cgroup-v2 activé par défaut dans RHEL 9
La fonctionnalité des groupes de contrôle version 2 (cgroup-v2) met en œuvre un modèle hiérarchique unique qui simplifie la gestion des groupes de contrôle. Elle garantit également qu'un processus ne peut être membre que d'un seul groupe de contrôle à la fois. L'intégration approfondie avec systemd améliore l'expérience de l'utilisateur final lors de la configuration du contrôle des ressources sur un système RHEL.
Le développement de nouvelles fonctionnalités est principalement effectué pour cgroup-v2, qui possède certaines fonctionnalités manquantes dans cgroup-v1. De même, cgroup-v1 contient certaines fonctionnalités héritées du passé qui sont absentes de cgroup-v2. En outre, les interfaces de contrôle sont différentes. Par conséquent, les logiciels tiers qui dépendent directement de cgroup-v1 peuvent ne pas fonctionner correctement dans l'environnement cgroup-v2.
Pour utiliser cgroup-v1, vous devez ajouter les paramètres suivants à la ligne de commande du noyau :
systemd.unified_cgroup_hierarchy=0 systemd.legacy_systemd_cgroup_controller
cgroup-v1 et cgroup-v2 sont tous deux pleinement activés dans le noyau. Il n'y a pas de version de groupe de contrôle par défaut du point de vue du noyau, et c'est systemd qui décide du montage au démarrage.
Modifications du noyau susceptibles d'affecter les modules tiers du noyau
Les distributions Linux dont la version du noyau est antérieure à la version 5.9 prenaient en charge l'exportation des fonctions GPL en tant que fonctions non GPL. Par conséquent, les utilisateurs pouvaient lier des fonctions propriétaires à des fonctions GPL du noyau par le biais du mécanisme shim. Avec cette version, le noyau RHEL incorpore des changements en amont qui améliorent la capacité de RHEL à appliquer la GPL en repoussant shim.
Les partenaires et les fournisseurs de logiciels indépendants (ISV) devraient tester leurs modules de noyau avec une version préliminaire de RHEL 9 pour s'assurer de leur conformité avec la GPL.
L'ordonnancement des noyaux est pris en charge dans RHEL 9
Grâce à la fonctionnalité de planification de base, les utilisateurs peuvent empêcher les tâches qui ne devraient pas se faire confiance de partager le même cœur d'unité centrale. De même, les utilisateurs peuvent définir des groupes de tâches qui peuvent partager un cœur d'unité centrale.
Ces groupes peuvent être spécifiés :
- Améliorer la sécurité en atténuant certaines attaques SMT (Multithreading symétrique)
- Pour isoler les tâches qui nécessitent un cœur entier. Par exemple, pour les tâches dans des environnements en temps réel, ou pour les tâches qui reposent sur des caractéristiques spécifiques du processeur telles que le traitement SIMD (Single Instruction, Multiple Data)
Pour plus d'informations, voir Core Scheduling.
La variable d'environnement kernelopts a été supprimée dans RHEL 9
Dans RHEL 8, les paramètres de la ligne de commande du noyau pour les systèmes utilisant le chargeur de démarrage GRUB2 étaient définis dans la variable d'environnement kernelopts. Cette variable était stockée dans le fichier /boot/grub2/grubenv pour chaque entrée de démarrage du noyau. Cependant, le stockage des paramètres de ligne de commande du noyau à l'aide de kernelopts n'était pas robuste. Par conséquent, Red Hat a supprimé kernelopts et les paramètres de la ligne de commande du noyau sont maintenant stockés dans le snippet Boot Loader Specification (BLS), au lieu du fichier /boot/loader/entries/<KERNEL_BOOT_ENTRY>.conf dans le fichier
Red Hat ne protège les symboles du noyau que pour les versions mineures
Red Hat garantit qu'un module du noyau continuera à se charger dans toutes les mises à jour futures au sein d'une version Extended Update Support (EUS), uniquement si vous compilez le module du noyau à l'aide de symboles protégés du noyau. Il n'y a pas de garantie d'ABI (Application Binary Interface) du noyau entre les versions mineures de RHEL 9.
