-----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
