[Linux-bruxelles] Utilité de "purger" une partition swap ?

[Laurent Léonard]

Le samedi 03 novembre 2007 à 00:13, Rémi Laurent a écrit :
> * Frederic Peters - 02-11-2007 à 23h44:
> > Une intéressante question que tu ne poses pas, c'est « pourquoi une
> > fois qu'il y a à nouveau de la place en mémoire vive le noyau n'y
> > déplace-t-il pas ce qu'il avait mis en swap ? »
> >
> > La réponse, c'est que la donnée à laquelle aucun processus n'accède,
> > elle peut très bien rester dans la swap, il sera toujours temps, quand
> > un processus en aura besoin, de l'en sortir pour la mettre en mémoire
> > vive.
> >
> >
> > J'espère que ça éclaire un peu, mais note bien que le fonctionnement
> > que je décris est un gros résumé, ce qui se passe réellement est un
> > poil plus complexe.
>
> Et puis ramener un processus de la swap en mémoire vive ça prend du
> temps. Si un processus est endormi depuis pas mal de temps il se peut
> qu'il se retrouve en swap pour laisser la place à d'autres plus
> gourmands. Si après la place en mémoire vive redevient suffisante il
> n'est pas forcément nécessaire de ramener ce processus endormi (par
> exemple un serveur ftp peut utilisé, un daemon fastcgi peu utilisé,
> des trucs pareils).
>
> Sinon le kernel utilise aussi un cache sur les données, je sais qu'il
> est utilisé pour le contenu du disque copié en mémoire, je ne sais pas
> s'il agit de la même manière pour le contenu mis en swap. Mais on peut
> imaginer la chose possible, le temps de recherche sur le filesystem et
> de lecture des différents blocs serait alors évité si on gardait une
> copie en cache, même si elle se trouve sur la swap.

Effectivement je n'avais pas pensé au coût du rapatriement de données de la 
swap vers la RAM, surtout si le processus est endormi ça n'en vaut pas la 
peine... 

Ca répond à ma question, merci à vous deux pour ces explications ! ;)

-- 
Laurent Léonard
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: signature.asc
Type: application/pgp-signature
Taille: 189 octets
Desc: This is a digitally signed message part.
URL: </pipermail/linux-bruxelles/attachments/20071103/2162b937/attachment-0001.sig>