Après que les folios de mémoire n’ont pas réussi à le faire dans Linux 5.15, cette modification de bas niveau du code de gestion de la mémoire du noyau qui a des implications possibles sur les performances cherche à atterrir pour Linux 5.16.
Avant la fenêtre de fusion Linux 5.16 qui pourrait s’ouvrir dès demain, Matthew Wilcox a envoyé sa pull request pour introduire des folios dans le noyau. Voici le principal extrait de la pull request pour ceux qui ne sont pas familiers avec les folios ou qui ont oublié les détails au fil des mois que cette fonctionnalité a été en préparation :
Le but de tout ce churn est de autoriser les systèmes de fichiers et le cache de page à gérer la mémoire en plus gros morceaux que PAGE_SIZE. Le plan initial était d’utiliser des pages composées comme le fait THP, mais j’ai rencontré des problèmes avec certaines fonctions n’attendant qu’une page d’en-tête tandis que d’autres attendent la page précise contenant un octet particulier. Le type folio permet à une fonction de déclarer qu’elle n’attend qu’une page d’en-tête. Presque incidemment, cela nous permet de supprimer divers appels à VM_BUG_ON(PageTail(page)) et compound_head().
Cette demande d’extraction ne convertit que des parties du MM principal et du cache de page. Pour la version 5.17, nous avons l’intention de convertir divers systèmes de fichiers (XFS et AFS sont prêts ; d’autres systèmes de fichiers peuvent le faire) et également de convertir une plus grande partie du cache MM et des pages en folios. Pour 5.18, les folios de plusieurs pages devraient être prêts.
Les folios multipages offrent une certaine amélioration à certaines charges de travail. La victoire de 80% est réelle, mais semble être une référence artificielle (démarrage postgres, ce qui n’est pas une charge de travail sérieuse). Les charges de travail réelles (par exemple, la construction du noyau, l’exécution de postgres dans un état stable, etc.) semblent bénéficier de 0 à 10 %. Je n’ai pas entendu parler de pertes de performances à la suite de cette série. Personne n’a fait de réglage sérieux des performances ; J’imagine que peaufiner l’algorithme de lecture anticipée pourrait fournir des gains plus intéressants. Il existe également d’autres endroits où nous pourrions choisir de créer de grands folios et ne le faisons pas actuellement, tels que des écritures supérieures à PAGE_SIZE.
Pour les utilisateurs finaux, cela signifie des gains de performances possibles et plus les versions ultérieures du noyau, la fonctionnalité autour des folios de mémoire seront construites.
Voir la pull request pour plus de détails. Maintenant, voyons si Linus Torvalds décide de retirer ces ~2k+ lignes de modifications ou si d’autres objections nouvelles/renouvelées sont soulevées à propos de l’ajout.
