Re: 'vidange' du swap
Yves Rutschle, vendredi 16 février 2007, 21:40:46 CET
>
> On Fri, Feb 16, 2007 at 05:30:11PM +0100, Sylvain Sauvage wrote:
> > > Le cache des fichiers est sauvegardé en swap? J'espère que
> > > non, ça parait sous-optimal :-)
> >
> > Vincent a répondu. J'ajouterais que :
> > ??? le swap, c'est de la mémoire, ça n'a pas de structure complexe
> > comme un FS et c'est effectivement plus rapide ;
>
> La seule différence me parait être qu'il faut mettre à jour
> un inode, donc un bloc de plus à écrire... Le reste est du
> calcul, négligeable par rapport à l'écriture proprement
> dite.
Écrire/lire à plusieurs endroits du disque en subissant plusieurs
indirections (structures du FS et abstractions intermédiaires) est
forcément plus long qu'écrire/lire des blocs de taille fixe (une page
mémoire), qui plus est quand ces derniers sont contigus (ce qui est le
cas pour une hibernation).
> > ??? le format utilisé par suspend (n'est pas celui du swap et) peut
> > être compressé, ce qui accélère la restauration.
>
> Logiquement, tous les FS devraient donc être compressés car
> ça devrait être plus rapide? Pourtant, les seuls FS
> compressés sont extrèmement particuliers (JFFS par ex.).
Cette phrase est une utilisation de la technique de l'homme de paille.
Je n'ai pas dit que la compression devrait être appliquée à toutes
les entrées-sorties fichier. Je n'ai pas dit que la compression était
une condition suffisante pour améliorer la vitesse de tout et n'importe
quoi.
J'ai dit que les buts de l'hibernation et les structures et
mécanismes utilisés permettaient d'utiliser la compression pour
augmenter la vitesse de l'hibernation et de la restauration. Et c'est
exactement ce qui est fait.
> J'ai du mal à suivre la logique.
Pour résumer le tout, la logique est la suivante :
But : on désire sauver tout l'état de la machine dans une mémoire
persistante.
Données à considérer :
1. quelques états, registres, noyau, données noyau... ;
2. la mémoire anonyme (mémoire allouée aux programmes pour leurs
données, pas les fichiers), laquelle occupe une partie de la RAM
(2r) et une partie du swap (2s) ;
3. les caches fichiers, programmes, bibliothèques et fichiers
ouverts. Certains sont en lecture seule et ne sont jamais allées en
RAM (3d), d'autres sont en cours de modification ou sont allées
faire un tour en RAM (3r).
Il est clair que 1. et 2. sont forcément à sauvegarder.
On peut aussi remarquer que 1. doit forcément être restauré en
mémoire (car ce n'est pas de la mémoire qui peut se trouver en swap).
Dans ce cas (celui où l'on a déjà besoin de replacer en RAM des blocs
entiers qui y étaient avant), et plutôt que de mettre en swap les
données 2r qui sont en RAM et de se retrouver avec des défauts de page
dans tous les sens au réveil, autant utiliser la même technique que
pour les données 1. : lire de gros blocs de RAM et les coller dans un
format ad hoc (pour ne pas dire tels quels) dans la partition de swap
(je n'ai pas dit la swap : c'est dans la partition de swap mais pas
sous la forme de swap), avec compression ou chiffrage au passage.
Les données 2s sont déjà dans la partition de swap, sous forme de
swap. On n'est pas obligé d'y toucher (sauf si on chiffre lors de
l'hibernation mais pas le swap normal (ce qui est un peu stupide)).
Une réallocation (défragmentation) peut être envisageable (je n'ai pas
fouillé les différents codes d'hibernation mais je crois que c'est
fait).
Les données 3d, celles qui sont des mmap en lecture seule, du code de
programmes et de bibliothèques, n'ont pas à être sauvegarder
puisqu'elles sont déjà sur le disque dans le bon état et les données 1.
contiennent déjà les informations nécessaires. Elles n'ont jamais été
dans la RAM.
Il nous reste les données 3r : le cache en RAM de fichiers plus ou
moins modifiés par rapport à leur état sur le disque.
Comme tu le disais dans un autre courriel, un mauvais programmeur
gère lui-même ses caches à gros coups de tampons plutôt que de laisser
le système le faire en utilisant des mmap. Et dans ce cas, ces tampons
se retrouvent dans les données 2.
Et bien on peut tout à fait considérer que Linux est très mal
programmé et qu'il utilise tout un tas de tampons (bon, il ne pouvait
pas être programmé autrement puisque c'est lui le système).
Donc les données 3r peuvent aussi être considérées comme des données
2r. Elles sont en RAM parce que le noyau a trouvé qu'il était opportun
de les y mettre, et ces raisons seront les mêmes au réveil : le noyau
les y remettra, mais pour chaque processus à son tour, avec les
embouteillages et les lectures à des emplacements dispersés, alors que
la restauration de l'hibernation peut le faire en n'écrivant/lisant que
des blocs contigus de taille fixe, et lorsqu'il est le seul à occuper
les ressources (cpu et disque).
En plus de ces raisons, il faut aussi prendre en compte un des
objectifs de l'hibernation : le système doit être le plus possible le
même après restauration qu'avant la sauvegarde. Je veux dire qu'elle ne
doit pas seulement restaurer les programmes en cours et leur état, ce
qui peut être fait en modifiant légèrement l'état du système (p.ex.
placer un morceau de mémoire en swap ou enlever un fichier du cache
n'est pas visible pour le programme touché (même si ça peut l'être pour
l'utilisateur)), mais qu'elle doit aussi être la moins invasive
possible pour le noyau, notamment au niveau du code. P.ex., je ne suis
pas sûr que le « sync » nécessaire pour les données 3r modifiées par
rapport au disque puisse être fait de façon sûre sans tripoter le noyau
un peu partout.
--
Sylvain Sauvage
Reply to: