Comment Windows peut-il vider la totalité de la RAM dans le fichier d'hibernation aussi rapidement ?

Il s'agit probablement d'une triple réponse.

Une chose qui peut être en jeu ici est le nouvel arrêt hybride de Windows qui ferme effectivement vos applications, vous déconnecte et procède ensuite à l'hibernation du noyau du système d'exploitation. Le fait d'avoir déjà sauvegardé ces données signifie qu'il n'est pas nécessaire de les "ré-hiberner" potentiellement.

La deuxième chose serait que l'hibernation n'aurait pas besoin de sauvegarder les pages de mémoire qui sont soit paginées dans le fichier d'échange, soit non utilisées (ce serait une raison pour remplir agressivement le fichier d'échange). y garder les données en mémoire également).

La troisième serait que le les données du fichier d'hibernation sont également compressées . Combinez cela avec mon deuxième point et si vous n'avez qu'un petit ensemble de données à exporter qui contient des données hautement compressibles (les exécutables sont généralement bien compressés), alors la quantité de données à envoyer au fichier d'hibernation peut être substantiellement plus petite que l'ensemble de données de travail. Notez que, comme indiqué dans les commentaires, les caches de fichiers et autres données inutiles de la mémoire tampon pourraient facilement être supprimés sans effet négatif pour réduire la quantité de données à déverser dans le fichier d'hibernation.

En outre, les disques durs actuels sont assez rapides. Avec un disque dont l'écriture soutenue est de l'ordre de 100 Mo/s, vous pourriez écrire (sans compression) 4 Go de RAM en moins d'une minute. Comme l'hibernation peut être effectuée en dernier lieu, après avoir suspendu tous les processus utilisateur et avant de suspendre le CPU, le système d'exploitation disposera généralement de la vitesse d'écriture totale du disque. C'est une chose que votre simple benchmark n'aura pas, et la copie de disque à disque sera potentiellement plus lente que la simple écriture de la RAM sur le disque.

En combinant ces éléments, la quantité de données à écrire dans le fichier d'hibernation pourrait être assez faible, potentiellement de l'ordre de 1 Go, et serait probablement écrite dans un grand bloc continu en moins de 10 secondes.

Tout d'abord, la quantité de RAM qui doit être sauvegardée est étonnamment faible. En fait, seul l'ensemble des pages sales mappées ("lazy writeback") doit être vidé, ainsi que toutes les pages privées sur lesquelles on a écrit et le code exécutable relocalisé.

• Les segments .text des exécutables sont toujours soutenus par le mappage des fichiers. C'est également vrai pour au moins un peu de DLL (mais pas toutes, cela dépend si elles doivent être déplacées).
• La mémoire qui est également soutenue par des mappages de fichiers peut être éliminée (en supposant qu'il ne s'agit pas de CoW ou de RW). y sale).
• Une réécriture paresseuse devra toujours avoir lieu, mais à part cela, les caches peuvent être éliminés.
• La mémoire qui a été allouée mais n'a pas été écrite (généralement la plus grande partie des données de l'application !) est soutenue par la page zéro et peut être mise au rebut.
• La plus grande partie des pages de mémoire qui sont en état de "veille" (l'ensemble de travail résident réel par processus sous Windows est étonnamment petit, à peine 16MB) aura été copié sur le fichier de page en arrière-plan à un moment donné et pourra être supprimé.
• Les régions de la mémoire qui sont mappées par certains périphériques tels que la carte graphique peuvent (éventuellement) ne pas avoir besoin d'être sauvegardées. Les utilisateurs sont parfois surpris de constater qu'ils branchent 8 Go ou 16 Go dans un ordinateur et que 1 Go ou 2 Go ont disparu sans raison apparente. Les principales API graphiques exigent que les applications puissent accepter que le contenu des tampons devienne invalide "dans certaines conditions" (sans dire exactement ce que cela signifie). Il n'est donc pas déraisonnable de s'attendre à ce que la mémoire qui est épinglée par le pilote graphique soit simplement jetée, elle aussi. L'écran va s'éteindre de toute façon, après tout.

Deuxièmement, contrairement à la copie d'un fichier, le vidage de l'ensemble des pages de RAM qui doivent être sauvegardées sur le disque est une seule écriture séquentielle et contiguë du point de vue du lecteur. L'API Win32 expose même une fonction fonction de niveau utilisateur pour cette même opération. L'écriture groupée est directement prise en charge par le matériel et fonctionne aussi vite que le disque est physiquement capable d'accepter des données (le contrôleur tirera directement les données via DMA).
Il y a un certain nombre de conditions préalables pour que cela fonctionne (comme l'alignement, la taille du bloc, l'épinglage), et cela ne joue pas bien avec la mise en cache et il n'y a pas de chose telle que le "lazy writeback" (qui est une optimisation très souhaitable en fonctionnement normal).
C'est la raison pour laquelle pas tous les écrits travaille comme ça tout le temps. Cependant, lorsque le système enregistre le fichier d'hibernation, toutes les conditions préalables sont automatiquement remplies (toutes les données sont alignées sur une page, de la taille d'une page et épinglées) et la mise en cache n'est plus pertinente car l'ordinateur va être éteint dans un instant.

Troisièmement, faire une seule écriture contiguë est très favorable tant pour les disques rotatifs que pour les disques à semi-conducteurs.

Le fichier d'échange et le fichier d'hibernation sont généralement parmi les premiers fichiers créés et réservés sur le disque. Ils ont généralement un, au plus deux fragments. Ainsi, à moins que les secteurs ne soient endommagés et que le disque doive réallouer des secteurs physiques, un logique L'écriture séquentielle se traduit par une physique écriture séquentielle sur un disque en rotation.

Aucune opération de lecture-modification-écriture n'est nécessaire sur le disque lorsqu'une énorme quantité de données séquentielles et contiguës est écrite. Ce problème est moins prononcé sur les disques durs rotatifs qui peuvent écrire des secteurs uniques assez petits (à condition de ne pas écrire des octets uniques, ce que la mise en cache empêche généralement, le périphérique n'a pas besoin de récupérer le contenu original et de réécrire la version modifiée).
Il s'agit toutefois d'un élément qui est très perceptible sur un SSD où chaque écriture signifie que, par exemple, un bloc de 512 Ko (c'est un nombre habituel, mais il pourrait être plus grand) doit être lu et modifié par le contrôleur, puis réécrit dans un bloc différent. Alors que vous pouvez en principe écrire sur (mais pas sur écraser ) des unités plus petites sur les disques flash, vous ne pouvez jamais effacer que de gros blocs, c'est ainsi que le matériel fonctionne. C'est la raison pour laquelle les disques SSD sont tellement plus performants sur les écritures séquentielles énormes.

Il ne vide pas toute la RAM au moment de l'hibernation.

Il aura déjà une grande partie de la RAM dupliquée sur le disque. Cela permet non seulement d'hiberner rapidement mais aussi de rendre la mémoire rapidement disponible pour les nouveaux programmes (afin qu'ils puissent se lancer rapidement).

Par conséquent, il ne doit écrire qu'une petite fraction des 4 Go et cela peut être fait en 10-15 secondes.

Desde microsoft :

Lorsque la RAM est rare (par exemple, le nombre d'octets engagés est supérieur à la RAM installée), le système d'exploitation essaie de conserver une certaine fraction de la RAM installée disponible pour une utilisation immédiate en copiant les pages de mémoire virtuelle qui ne sont pas en cours d'utilisation dans le fichier de pages. Par conséquent, ce compteur n'atteindra pas zéro et n'est pas nécessairement une bonne indication pour savoir si votre système manque de RAM.

En plus de tout ce qui précède, je pense qu'il y a quelques autres facteurs en jeu.

L'une d'elles est que, lors de la copie d'un fichier, celui-ci doit être lu et écrit ; l'hibernation ne nécessite que l'écriture du fichier. Il est, par définition, déjà en mémoire !

Dans le même ordre d'idées, lorsqu'on lit un fichier et qu'on l'écrit en même temps, pour économiser de la mémoire, le processus est le suivant : lire un morceau, écrire un morceau, mettre à jour le répertoire (pour indiquer la nouvelle taille) ; lire un morceau, écrire un morceau, mettre à jour le répertoire.

Chaque fois que vous passez d'une partie du disque à une autre (par exemple, lire le fichier a pour écrire le fichier b, écrire le fichier b pour écrire le répertoire, et écrire le répertoire pour lire le morceau suivant), le disque doit chercher - déplacer les têtes, laisser les têtes se poser, attendre que la bonne partie du disque passe. C'est l'un des avantages d'un disque dur : la recherche ne prend pas de temps du tout. En hibernation, les données sont écrites de bout en bout. Le fichier d'hibernation (swap) est pré-alloué, le répertoire n'a donc pas besoin d'être mis à jour (vous ne modifiez pas la taille du fichier d'hibernation, seulement son contenu).

Et enfin, votre ordinateur a suspendu toutes les autres tâches - c'est la SEULE chose qu'il fait (je doute que cela fasse une grande différence, mais il y en a forcément une !) Même des choses comme la gestion de la mémoire et le changement de tâche sont suspendues.

Cela est probablement dû au fait que la RAM a des vitesses d'entrée/sortie beaucoup plus rapides que le disque dur, de sorte que la RAM peut sortir les données qu'elle contient aussi rapidement que le disque dur peut les lire.

Lorsque vous copiez des fichiers, vous êtes également limité par différents facteurs : la vitesse du disque, s'il doit être lu et relu sur le même disque, cela prendra plus de temps, la vitesse limitée de la connexion (s'il s'agit d'un disque externe), la vérification qu'il n'écrase rien, etc.