-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
C'est ce que je pensais avoir expliqu� de fa�on compr�hensible dans mon mail pr�c�dent lol ;))- Une importante : Lors de l'initialisation d'un process, il peut y avoir des pages qui sont uniquement utilis�e lors de l'initialisation du processus lui-m�me. Mais bien entendu, durant la vie du process ces pages sont en m�moires et ne sont jamais utilis�es... C'est pour cela que plac�e dans le "swap" cela permet d'�viter d'utiliser de la m�moire vive pour rien..
Non, en effet, elle n'est pas copi�e dans le swap - pas au chargement en tout cas.Tu es sur de cela, je pensais que l'image du process etait mapper ( via mmap ) dans de la memoire du process, mais pas copier dans le swap.
La partie code (le code machine �x�cut� donc) est copi� en m�moire virtuelle (en RAM � l'utilisation, �videmment ;)) par pages acc�d�es (afaik sous linux), �videmment avec du pr�chargement (prefetch) et autres astuces pour am�liorer les performances - �a c'est (notamment) le boulot du VM (= gestionnaire de m�moire virtuelle).
Par la suite, les pages de code sont �galement "swapped out" (donc d�localis�es de la m�moire physique (RAM) vers la swap), tout comme les pages de data (pour le heap).
Aucun rapport. L'adressage n'a rien � avoir avec �a (ou alors je ne vois pas ce que tu veux dire ;))).- Sauf dans le cas d'une relocation en memoire d'un lib, car il y a lieu de modifier l'addressage du process/shared lib. Mais de toutes facons on utilise le 'copy on write' pour faire cela.
Les pages de code des shared libs ne sont charg�es qu'une seule fois en m�moire virtuelle (= m�moire physique + swap), c�d que si 50 programmes utilisent p.ex. libgtk-1.2.so.0, les pages de code de libgtk-1.2.so.0 ne seront charg�es qu'une seule fois en m�moire.
Les parties modifiables (stack et heap) sont de toute mani�re propres aux processus: - - le heap est allou� dans des segments de data attach�s aux processus, et pas � la shared lib - - le stack �galement
Sur les pages de data, �videmment, on a le copy-on-write aussi, c�d que les pages mises en commun entre processus ne sont dupliqu�es que lorsque l'on les modifie.
Je ne vois pas ce que tu veux dire avec l'adressage.
L'adressage en tant que pointeur d'�x�cution est dans le contexte de chaque processus (d'o� le "context switch" quand le scheduler (*) fait passer le(s) processeur(s) d'un/des processus � un/des autre(s))
(*) le scheduler est la partie du kernel qui r�partit le temps processeur entre les processus en �x�cution, ce qui permet d'�x�cuter plus d'un processus "en m�me temps" - et cela en fonction de la pond�ration de chaque processus (priorit�), du nombre de processeurs disponibles, des attentes des processus envers des acc�s hardware, etc...
(et ne parlons m�me pas du "CPU affinity" qui va passer dans le trunk du 2.6.0 (je suppose))
Enfin, c'est c'etait comme ca sous NT, pas sous Linux ?Bein c'est quand m�me mieux fait sous Linux que NT, alors... ;)
Remarque, le noyau NT ne doit quand m�me pas �tre trop mauvais, mais Linux est plus performant en terme de context switch (�norm�ment sur les processus (windows est tr�s mauvais sur les context switch de processus, c'est bien connu), mais �galement sur les threads) et sur la gestion de la m�moire.
Nuance, nuance... ;)Si ce que je pense est vrai, si un process n'utilise plus des zones de prg, celle-ci sont 'swapped out' mais, comme c'est pas mapper dans le swap cela ne fait simplement rien.
Des pages d'un processus peuvent tr�s bien avoir �t� charg�es au d�but de l'�x�cution du programme (comme l'exemple d'Alex) puis ne plus �tre acc�d�es par la suite (ou du moins pendant un bon bout de temps), p.ex. des s�quences d'initialisations.
Ces pages-l� sont en m�moire virtuelle car elles doivent �tre �x�cut�es. Mais par la suite, si le VM en ressent le besoin (principalement en fonction de la m�moire physique disponible) il va faire un "swap-out" sur ces pages.
Effectivement, �tant donn� que les pages de code sont des pages read-only, elles seront simplement "discarded" (donc sorties de la m�moire virtuelle) et n'iront pas en swap.
Mais en ce qui concerne les parties data (heap, stack) et donc les pages en read/write, les pages ne sont pas "discarded" mais vraiment "swapped out" (en swap ;)).
Il est possible que le kernel fasse en plus une distinction entre les pages read/write effectivement modif�es (qu'il ne peut donc perdre en aucun cas et sur lesquelles il ne fera jamais de discard tant que le processus propri�taire de ces pages sera en �x�cution) et celles qui n'ont pas (encore) �t� modifi�es (sur lesquelles le VM pourrait faire un "discard").
Je ne suis pas persuad� de l'utilit� d'un swap sur des stations de travail mais sur des machines � haute charge processus et/ou m�moire, �a a beaucoup de sens.
Une chose aussi � propos de l'optimisation: il faut toujours faire travailler _toutes_ les ressources. Ce n'est pas parce que la swap est (beaucoup) plus lente que la m�moire physique qu'il ne faut pas l'utiliser. Evidemment, il faut beaucoup moins l'utiliser ;))
Un exemple: quand tu optimises une grosse DB Oracle, tu ne mets pas _tout_ en SGA (**), p.ex. en faisant du pinning et en mettant un cache monstrueux. Sinon la m�moire physique va �tre utilis�e � gogo (ce qui est bien, �tant donn� que c'est la ressource la plus rapide), mais tes disques ne seront plus utilis�s du tout (car toutes les donn�es seront en cache). Il faut que les disques soient utilis�s �galement, mais � bon escient.
(**) SGA: Shared Global Area: zone m�moire foutoir d'Oracle dans lequel il met tous les caches, les plans d'�x�cution de requ�tes (execution plans), etc...
Bon, �a suffit sinon on va faire peur aux autres ;)))
NB: les tr�s courtes explications que j'ai mis � gauche et � droite c'est pas pour toi mais pour ceux qui n'ont pas le plaisir de conna�tre les entrailles des syst�mes d'exploitations... si jamais ils ont le courage de lire, ils comprendront p-e un tout petit peu mieux avec �a ;)
- -- -o) Pascal Bleser http://guru.unixtech.be
/\\ <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
_\_v The more things change, the more they stay insane.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQE/VNsnr3NMWliFcXcRAsH0AKCjkuaObBvyyY1P89FC/t2gh65xEgCfbO2L w2Hg7lh4ty+jWUFtoYHYpEE= =9NWl -----END PGP SIGNATURE-----
_______________________________________________________ Linux Mailing List - http://www.unixtech.be Subscribe/Unsubscribe: http://www.unixtech.be/mailman/listinfo/linux Archives: http://www.mail-archive.com/[EMAIL PROTECTED] IRC: efnet.unixtech.be:6667 - #unixtech
