mon dieu keen affaire (je m'imagine en train d'optimiser les acces a une DB oracle .. beurk). Mes considerations de taille au boulot sont plus proche de 200k de code optimise a fond pour l'embarque. Amusant tout de meme la difference des 2 mondes. (y a pas de swap sur le speedtouch (ni meme de VM a proprement parler dailleur) ;) , tout tiens dans 4/8Mo de ram.
On Tue, 2003-09-02 at 20:02, Pascal Bleser wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >>- 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.. > C'est ce que je pensais avoir expliqué de façon compréhensible dans mon mail > précédent lol ;)) > > > 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. > Non, en effet, elle n'est pas copiée dans le swap - pas au chargement en tout cas. > 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). > > > - 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. > Aucun rapport. L'adressage n'a rien � avoir avec ça (ou alors je ne vois pas ce > que tu > veux dire ;))). > 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. > > > 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. > Nuance, nuance... ;) > > 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 -- -> Jean-Francois Dive --> [EMAIL PROTECTED] There is no such thing as randomness. Only order of infinite complexity. - Marquis de LaPlace - deterministic Principles - _______________________________________________________ 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
