Comment Windows peut-il vider le RAM complet dans le fichier d'hibernation aussi rapidement?
Je passais à travers un article qui expliquait la procédure de veille prolongée dans Microsoft Windows. Les principaux points que j'en tire sont
- Windows vide tout le RAM (après l'avoir traité éventuellement) dans le fichier
hiberfil.sys. - Pendant le démarrage, le fichier d'hibernation est lu et le contenu est chargé dans la RAM.
Ma question est lorsque je copie habituellement un fichier de taille, disons, 1 Go, il faut environ 2 minutes pour terminer.
Cependant, lorsque Windows écrit le fichier d'hibernation (au cours de la procédure d'hibernation), le processus complet prend environ 10 à 15 secondes. Pourquoi la vitesse d'écriture est-elle si différente?
Ma taille RAM est de 4 Go. (Je ne parle pas de technologie d'amorçage rapide.)
Benchmarks:
- Copie d'un fichier de 1 Go d'un disque 1 à l'autre (externe): 2,3 minutes.
- Veille prolongée du système: 15 secondes.
C'est probablement une triple réponse.
Le nouvel arrêt hybride de Windows, qui ferme efficacement vos applications, vous déconnecte, puis met en veille prolongée le cœur du système d’exploitation, fait partie des éléments à prendre en compte. Avoir déjà ces données sauvegardées signifierait qu'il n'est pas nécessaire de les "hiberner" potentiellement.
La deuxième chose est que l'hibernation n'aurait pas besoin de sauvegarder les pages de mémoire qui sont paginées dans le fichier d'échange ou non utilisées (ce serait une raison pour remplir agressivement le fichier d'échange et conserve également les données en mémoire).
La troisième serait que les données du fichier d'hibernation soient é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), la quantité de données à envoyer au fichier d'hibernation peut être considérablement plus petite que le jeu de travail. de données. Notez que, comme indiqué dans les commentaires, les caches de fichiers et autres données de tampon inutiles pourraient facilement être supprimés sans effet néfaste, ce qui réduirait la quantité de données à dumper dans le fichier de veille prolongée.
De plus, les disques durs actuels sont assez rapides. Avec un disque ayant une écriture soutenue de l’ordre de 100 Mo/s, vous seriez en mesure d’écrire (non compressé) 4 Go de RAM en moins d’une minute. Comme l'hibernation peut être effectuée en dernier lieu après la suspension de tous les processus utilisateur et avant la suspension du processeur, le système d'exploitation aura généralement la vitesse d'écriture maximale du disque. C’est une chose que votre simple benchmark ne possédera pas et la copie d’un disque à l’autre sera potentiellement plus lente que la simple écriture RAM sur le disque.
Si vous combinez ces éléments, la quantité de données à écrire dans le fichier d'hibernation pourrait être assez petite, potentiellement de l'ordre de 1 Go, et serait probablement écrite dans un grand bloc continu en moins de 10 secondes.
Premièrement, la quantité de RAM à sauvegarder est étonnamment faible. En fait, seuls les ensembles de pages modifiées mappées ("écriture différée") doivent être vidés, de même que toutes les pages privées écrites et le code exécutable déplacé doivent être écrites.
- Les segments .text des exécutables sont toujours sauvegardés par un mappage de fichier. Cela est également vrai pour au moins certaines DLL (mais pas toutes, cela dépend si elles doivent être déplacées).
- La mémoire qui est pareillement sauvegardée par des mappages de fichiers peut être supprimée (il est présumé que ce n'est pas CoW ou RW et sale).
- L'écriture différée doit encore se produire, mais à part cela, les caches peuvent être supprimés.
- La mémoire allouée mais non écrite (généralement la plus grande partie des données de l'application!) Est sauvegardée par la page zéro et peut être supprimée.
- La plus grande partie des pages de mémoire en état de veille (le jeu de travail réel par processus sous Windows est étonnamment petit, à peine 16 Mo) aura été copié dans le fichier de page. en arrière-plan à un moment donné et peut être jeté.
- Les régions de la mémoire 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 d’avoir branché 8GiB ou 16GiB à un ordinateur, et 1GiB ou 2GiB sont simplement "partis" sans raison apparente. Les principales API graphiques exigent que les applications puissent annuler le contenu de la mémoire tampon "dans certaines conditions" (sans indiquer exactement ce que cela signifie). Il n’est donc pas déraisonnable de s’attendre à ce que la mémoire bloquée par le pilote graphique soit également supprimée. De toute façon, l’écran va s’éteindre, après tout.
Deuxièmement, contrairement à ce que vous copiez un fichier, le vidage de l'ensemble de RAM pages à enregistrer est une écriture séquentielle unique et contiguë du point de vue du lecteur. L'API Win32 expose même une fonction de niveau utilisateur pour cette opération même. La collecte d'écriture est directement prise en charge par le matériel et fonctionne aussi rapidement que le disque est physiquement capable d'accepter des données (le contrôleur extraira directement les données via DMA).
Il existe un certain nombre de conditions préalables à son fonctionnement (telles que l’alignement, la taille de bloc, l’épinglage), et cela ne fonctionne pas bien avec la mise en cache et il n’existe pas de "réécriture différée" optimisation souhaitable en fonctionnement normal).
C'est la raison pour laquelle toutes les écritures ne fonctionnent pas comme cela 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, redimensionnées et épinglées) et la mise en cache est devenue inutile car l'ordinateur va être éteint dans un instant.
Troisièmement, faire une seule écriture contiguë est très favorable à la fois pour les disques tournants et pour les disques à l'état solide.
Le fichier d'échange et le fichier d'hibernation sont généralement des fichiers parmi les plus anciens créés et réservés sur le disque. Ils en ont généralement un, au plus deux fragments. Ainsi, sauf si des secteurs sont endommagés et que le disque doit réaffecter des secteurs physiques, une écriture séquentielle logique se traduit par une écriture séquentielle physique sur un disque en rotation.
Aucune opération de lecture-modification-écriture n'est nécessaire sur le disque lorsqu'une très grande quantité de données séquentielles contiguës est en cours d'écriture. Ce problème est moins prononcé sur les disques durs en rotation qui peuvent écrire des secteurs simples qui sont assez petits (à condition de ne pas écrire d'octets simples, ce que la mise en cache empêche généralement, le périphérique n'a pas besoin d'extraire le contenu d'origine ni de réécrire la version modifiée.) .
C’est cependant quelque chose qui est très perceptible sur un disque SSD, chaque écriture signifiant par exemple que. 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 autre bloc. Bien que vous puissiez en principe écrire sur (mais pas écraser ) des unités plus petites sur des disques flash, vous ne pouvez jamais effacer d'énormes blocs, c'est ainsi que fonctionne le matériel. C'est la raison pour laquelle les disques SSD se débrouillent tellement mieux sur les énormes écritures séquentielles.
Il ne vide pas tout le RAM au moment de l'hibernation.
Une grande partie de la RAM sera déjà dupliquée sur le disque. Cela permet non seulement une mise en veille prolongée rapide, mais également une mémoire rapidement disponible pour les nouveaux programmes (afin qu'ils puissent être lancés rapidement).
Par conséquent, il suffit d'écrire une petite fraction des 4 Go, ce qui peut être fait en 10-15 secondes.
De Microsoft :
Lorsque RAM est en rupture de stock (par exemple, Octets validés est supérieur à la RAM installée), le système d'exploitation tente de garder une certaine fraction de RAM installée disponible pour une utilisation immédiate par copie. Les pages de mémoire virtuelle qui ne sont pas utilisées activement dans le fichier d'échange. Par conséquent, ce compteur n’atteindra pas zéro et n’indiquera pas nécessairement si votre système manque de mémoire vive.
En plus de tout ce qui précède, je pense qu'il y a quelques autres facteurs en jeu.
La première est que, lors de la copie d’un fichier, celui-ci doit être lu et écrit; hybernation exige seulement que le fichier soit écrit. C'est, par définition, déjà en mémoire!
De manière étroitement liée à cela, lors de la lecture et de l’écriture simultanées d’un fichier, le processus consiste à économiser de la mémoire: lire un morceau, écrire un morceau, mettre à jour le répertoire (pour afficher 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, lisez le fichier a pour écrire le fichier b, écrivez le fichier b pour écrire le répertoire et écrivez le répertoire pour lire le bloc suivant), le disque doit chercher - déplacer les têtes, laissez les têtes s'installer, attendez que la partie droite du disque passe. C'est l'un des avantages d'un disque SSD: la recherche ne prend pas de temps. En mode hibernation, les données sont écrites de bout en bout. Le fichier d'hibernation (swap) est pré-alloué. Il n'est donc pas nécessaire de mettre à jour le répertoire (vous ne modifiez pas la taille du fichier d'hibernation, mais uniquement 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 cela en fera forcément!). Même des éléments tels que la gestion de la mémoire et le changement de tâche sont suspendus.
Ceci est probablement dû au fait que RAM a des vitesses d’entrée/sortie beaucoup plus rapides que le disque dur, de sorte que le RAM puisse sortir les éléments qu'il contient aussi rapidement que le disque dur peut les lire.
Lors de la copie de fichiers, vous êtes également limité par divers facteurs - la vitesse du disque, si elle doit être lue et relue sur le même disque, cela prendra plus de temps, la vitesse limitée de la connexion (sur un lecteur externe), vérifiée n'écrase rien, etc.