La semaine dernière commencé à travailler sur quelle sera la prochaine version du noyau de Linux 6.5 et depuis lors certains des changements les plus pertinents ont déjà commencé à être annoncés qui sera introduit dans cette prochaine version du noyau.
Et c’est que, par exemple, un grand nombre d’améliorations et de changements ont déjà été intégrés, comme le prise en charge du démarrage parallèle du processeur Dans le but de réduire considérablement les temps de démarrage du noyau, AMD modifie avec diligence les problèmes de suspension/reprise du système, ainsi que des améliorations des systèmes de fichiers, de la virtualisation, etc.
Parmi les changements annoncés, nous parlerons de l’un d’eux dans cet article, qui est mentionné comme ayant déjà été inclus dans la base de code qui construit le noyau Linux 6.5 et a été intégré à l’implémentation de un nouvel appel système “cachestat”.
Cette série de correctifs introduit un nouvel appel système, cachestat, qui résume les statistiques du cache de pages (nombre de pages en cache pages marquées pour réécriture, pages évincées, etc.) d’un fichier, dans un plage d’octets spécifiée. Il comprend également une suite d’auto-tests qui teste certains utilisation typique.
À propos de cachestat
cachestat est un nouvel appel système qui permet aux programmes utilisateur d’interroger des statistiques de cache de page plus détaillées du côté du noyau. En tant que tel, il est prévu d’étendre l’appel système mincore déjà existant qui est utilisé pour déterminer si des pages sont présentes en mémoire, l’appel cachestat permet des statistiques de cache de page plus détaillées et indique une plus grande évolutivité.
Il est mentionné que actuellement la mémoire du cache de page est généralement le plus gros consommateur de mémoire et par conséquent, les méthodes du noyau qui le gèrent ont un impact important sur les performances. En tant que tel, il existe une interface riche pour augmenter ces méthodes avec fadvise et la famille de synchronisation.
L’appel système cachestat() envoie des informations sur le nombre de pages stockées mises en cache, pages modifiées, pages supprimées, pages récemment supprimées et pages marquées pour réécriture.
Les statistiques fournies pour les dossiers vous permettent de prendre des décisions plus précises sur le travail avec les E/S qui passent par le VFS, basé non seulement sur un algorithme abstrait, mais prenant également en compte les caractéristiques d’un système particulier à un moment donné.
Il n’existe actuellement aucun bon moyen d’interroger l’état de la grande page de cache ensembles de fichiers et arborescences de répertoires. Il y a mincore(), mais ça évolue mal :
le noyau écrit une grande quantité de données bitmap que l’espace utilisateur doit ajoutez-le, lorsque l’utilisateur ne se soucie pas vraiment des informations par page
dans ce cas. L’utilisateur doit également mmmap et désallouer chaque fichier au fur et à mesure tout au long, ce qui peut aussi être assez lent.
À propos de la pCas d’utilisation possibles de cachestat() par les applicationset mentionnez ce qui suit :
- Le planificateur de requêtes dans le SGBD pourra décider d’effectuer un parcours d’index ou de lire directement les données de la table en fonction de l’état de l’index de la table dans le cache de page.
- Gestion granulaire et dépendante de la charge du remplissage du cache de page et des E/S (par exemple, pages sales/pages marquées pour la réécriture), en changeant la fréquence de synchronisation, de très fréquente sous une faible charge à rafale pendant les rafales de charge.
- Possibilité d’une présentation plus visuelle et un affichage pratique des informations d’utilisation de la mémoire sur les fichiers/répertoires volumineux, similaire à la façon dont l’utilitaire “du” vous permet d’afficher l’utilisation de l’espace disque.
- Dépannage et débogage plus faciles des écritures différées pour les problèmes de performances.
Finalement Si vous êtes intéressé à en savoir plus à ce sujetvous pouvez vérifier les détails dans le lien suivant.