Que contrôle réellement le paramètre vm.swappiness?

Selon la documentation du noyau:

This control is used to define how aggressive the kernel will swap
memory pages.  Higher values will increase aggressiveness, lower values
decrease the amount of swap.

Cependant, c'est un peu vague. J'essaie de comprendre exactement ce que le paramètre contrôle en fin de compte. Je sais que cela ajuste l'agressivité du noyau pour échanger les pages, mais quel processus de prise de décision dans le code du noyau affecte-t-il?

Est-ce qu'il ajuste depuis combien de temps une page doit avoir été accédée avant que le noyau ne la remplace? Si tel est le cas, que représente la valeur par défaut de 60? Et combien est changé par un incrément / décrément de 1 (une formule serait bien)?
Ou remplace-t-il les pages en fonction de leur fréquence d'accès?
Ou autre chose?

Depuis la version 2.6.28 du noyau, Linux utilise un de Split les moins récemment utilisés (MRU) Page stratégie de remplacement. Les pages avec une source de système de fichiers, telles que le texte du programme ou les bibliothèques partagées, appartiennent au cache de fichiers. Les pages sans système de fichiers s'appellent des pages anonymes et se composent de données d'exécution telles que l'espace de pile réservé aux applications, etc. En règle générale, les pages appartenant au cache de fichiers coûtent moins cher à expulser de la mémoire (car elles peuvent être simplement relues à partir du disque en cas de besoin). . Etant donné que les pages anonymes n’ont pas de sauvegarde de système de fichiers, elles doivent rester en mémoire aussi longtemps qu’elles sont nécessaires à un programme, sauf s’il existe un espace d’échange pour les stocker.

L' vm.swappinessoption entre en jeu get_scan_count()définie dans mm/vmscan.c. get_scan_count()détermine à quel point les listes des LRU anonymes et des fichiers doivent être analysées de manière agressive lorsque vous recherchez des pages à expulser La valeur de chaque cas est déterminée par la moyenne flottante des ratios récemment pivotés et scannés, dans lesquels les références plus récentes ont plus de poids que les anciennes, afin de prendre en compte l’évolution de la charge de travail du système.

Le vm.swappinessest un modificateur qui modifie l'équilibre entre permuter les pages de cache de fichiers en faveur de pages anonymes. vm.swappinessest la valeur de priorité donnée aux pages anonymes, définie par défaut à 60 . Le cache de fichier se voit attribuer une valeur de priorité de 200 à partir de laquelle le vm.swappinessmodificateur est déduit ( file_prio=200-anon_prio). Cela signifie que, par défaut, les poids de priorité sont modérément favorables aux pages anonymes ( anon_prio=60, file_prio=200-60=140). Toutefois, lorsque le système est proche d'un out-of-mémoire état , tous les deux listes LRU anonymes et fichiers sont analysés de manière égale, à moins vm.swappinessest mis à zéro.

Quand vm.swappinessest défini sur 100, les priorités seraient égales ( anon_prio=100, file_prio=200-100=100). Mettre vm.swappinessà zéro empêchera le noyau d'expulser les pages anonymes en faveur des pages du cache de fichiers.

Une formule est utilisée pour calculer quelle page sera échangée. Dans vmscan.cvous pouvez voir cet algorithme:

tendance d'échange = mapped_ratio / 2 + détresse + vm_swappiness

Ici, vous pouvez voir que swappiness est une échelle, qui est ajoutée à un algorithme et vous pouvez contrôler par ce paramètre le comportement du noyau lorsqu’il doit échanger. Vous pouvez comprendre en pourcentage de probabilité qu'une page inactive de la mémoire sera permutée. Si vous définissez swappiness sur 100, il n'y a aucune probabilité, mais une garantie qu'il sera échangé et si vous le définissez sur 0, le noyau essaiera de ne pas échanger du tout tant qu'il aura de la mémoire vide.

Il a été dit (je pense que Norman 1986) que souvent le bouton "FERMER LA PORTE" dans un ascenseur est soit cassé, soit jamais connecté à quoi que ce soit en premier lieu. Cela fait du contrôle de l'ersatz non pas un moyen de manipuler l'ascenseur mais de calmer le coureur pressé.

De manière similaire, swappiness a un effet sans rapport avec son contrôle déterministe bien défini d'un prédicat de noyau. Comme l'a noté @neon_overlord sur askubuntu.com

Parce que la plupart croient que le swapping = bad et que si vous ne réduisez pas le swappiness, le système permutera s'il n'est pas nécessaire. Aucune de celles-ci n'est vraiment vraie. Les gens associent les échanges aux moments où leur système est en train de s'enliser. Cependant, il s'agit surtout d'échanges parce que le système s'enlise, et non l'inverse. Il est vrai que, dans certains cas, l’échange peut entraîner une pénalité notable, mais la réduction de la rapidité de traitement de ce cas peut réduire les performances globales du système ou la stabilité de d’autres manières qui pourraient devenir perceptibles plus tard…

Alors que contrôle-t- il vraiment ? Une réponse valable - en plus des réponses précises déjà fournies - est que cela modifie vos attentes en termes de contrôle accru de votre système et que le fait de tourner un bouton vous permet d'exercer ce contrôle de manière significative.