Reutilisation/Duplication de pages, suite (re: Wine & TX)

Page principale

Répondre à ce message
Auteur: Michel RIX
Date:  
À: guilde
Sujet: Reutilisation/Duplication de pages, suite (re: Wine & TX)

AU SUJET DES REUTILISATIONS/DUPLICATIONS DE PAGES SOUS UNIX :



> Date: Wed, 15 Jul 1998 08:26:20 -0700
> Subject: Re: Wine & TX
>
>> > Date: Fri, 10 Jul 1998 15:35:53 +0200
>> > Subject: Wine & TX
>> >
>> > Dans la configuration :
>> > 1 serveur et n Terminaux X utilisant simultanemment Wine et un exe W3.1
>> > Wine et l'exe seront ils charg=E9s n fois ?
>> > Ou 1 fois pout tout les clients ?
>> >
>>
>> IDEE = Principe du "copy on write" :
>>
>> Memoire Virtuelle et Buffer Cache :
>> Une fois qu'une page est en memoire, elle est utilisee par tous.
>> Lorsqu'il y a ecriture (modification) sur une page, celle-ci est dupliquee :
>> une meme page n'est jamais relue sur disque ni dupliquees en memoire.
>> Ce principe est le meme pour le buffer cache (gestion des fichiers :
>> open read/write close) et pour la memoire virtuelle (espace d'adressage des
>> processus), mais separement : une meme page peut etre en memoire virtuelle
>> et en buffer cache.
>>
>> NB, Cas d'un Espace Memoire Unique :
>> Sur une meme machine :
>> lorsque les espaces de memoires virtuelles et buffers caches ont une gestion
>> unique (Linux, Aix, systeme V.4, BSD.4, ...) : il n'y a meme plus de
>> duplication possible entre memoire virtuelle et buffer cache.
>> Sur un ensemble de machine : c'est un autre sujet!
>>
>>
>> CONSEQUENCE :
>> Dans un espace virtuel, les donnees non modifiables ne sont jamais dupliquees
>> par exemple le code des applications : Wine, exe W3.1, ...
>>
>>
>>
>>
>> Michel
>
> Il me semblait que le copy-on-write dans le noyau Linux ne s'appliquait
> qu'au fork. En d'autres termes si le processus p1 forke un processus p2,
> p1 et p2 vont effectivement partager les memes pages jusqu'au moment
> ou l'un des 2 va ecrire sur une des pages, ce qui provoquera le copy on
> write.
> Si un meme programme est lance n fois, les librairies partagees seront
> partagees comme leur nom l'indique. Mais comment le programme (i.e.
> l'executable sans les lib dynamiques) lui-meme pourrait-il l'etre, a moins
> que les n processus aient le meme parent?
>



Desole je ne suis pas suffisamment competent sur linux,
neanmoins j'ai reuni un peu plus de details :

- Les differentes modifications du noyaux unix s'ameliorent et se copient 
les unes le autres.
- SystemVR3 connait le "copy on write" (sur fork) contrairement a BSD4.3.
- Le buffer cache des fichiers introduit des references aux pages par les
couples <device, block> dans des listes chainees, qui evitent les duplications
de page.
- System5R3,  BSD4.3 ne dupliquent pas les pages de texte : action au niveau
de la region (attachement).
- En systemVR4, mach, BSD4.4 Toutes les pages sont identifiees par un couple
( <vnode, offset>, <objet, offset> ) et on peut maintenant eviter toute
duplication de page.
Et pas seulement les pages en lectures seules, grace a la generalisation
de la duplication sur modification (introduite d'abord par SVR4 je crois).
- Le partage au niveau page est transparent a l'utilisateur, ne pas 
confondre avec la memoire partagee explicitement pour les donnees communes.
- Il me semble que les bibliotheques partagees ont les avantages suivant :
   . Gestion securisee et facilisee (hors programme utilisateur),
   . Rapidite : dans l'espace utilisteur et non dans le noyau,    
                pas d'augmentation de taille ni en memoire virtuelle
                    utilisateur ni dans celle du noyau,
   . Partage (bien sur) : si les pages de code commun etaient integrees au 
programme, le systeme ne saurait pas qu'elles sont identiques d'un programme
a un autre, a condition qu'elles le soient (elles pouraient etre cadrees
differemment d'un programme a un autre...).
- Mes connaissances, recentes, de linux m'apprennent d'une part qu'il 
integre gestion de fichiers avec gestion des memoires virtuelles, 
comme SVR4, mach, BSD4.4   et d'autre part qu'il est recent.



Michel