[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [linux-team] processus et segments



Pour info: Je corige.

Les pages sont bien taggees avec un access READ ou RW. Cela cree des segments qui n'ont pas forcement rapport au segments geres par le processeur. Il _peut_ y avoir mapping entre les deux mais ce n'est pas obligatoire.

Donc, sous Unix, il y a bien un segment DATA et un segment TEXT au moins. Sous tous les Unix que je connais, il y a aussi un segment KERNEL. On trouve egalement un segment shared (pour les DLL's). Ce que l'on appelle le DATA segment (c'est un segment logique, i.e. pour la facilite d'expression) est splitte en 2: HEAP et STACK. Linux gere tous ces segments avec des vm_area_struct (ca, je n'avais pas vu avant).

Pour ce qui est de l'allocation, le kernel se fiche du malloc. (a ma connaissance toujours) il n'y a qu'un seul appel systeme qui dit au kernel l'adresse memoire maximum de la heap utilisee par un process. C'est l'appel BRK. Le zones allouees ou liberees par malloc et free sont des notions du user space seulement.

En clair, malloc regarde s'il a reserve assez de place au niveau du kernel (pour la heap)

1) Si oui, il "note" le bloc alloue et retourne un pointeur a l'appelant. Le tout en user space.

2) Sinon, malloc appelle le kernel et lui dit d'etendre la zone de heap jusqu'a l'adresse xyz. Le kernel update la table des pages pour permettre un eventuel "page fault" qui provoquerait le mapping vers une page physique. Quand l'appel system retourne (et s'il reussit), malloc alloue un bloc de memoire comme au point (1).

Dans Linux, une page de memoire virtuelle non utilisable (cas non mappee) a un tag PG_reserved.

Je n'ose pas trop m'aventurer bcp plus loin parce que je ne suis pas un guru du machin. Je repond de memoire et je confirme avec le code sous les yeux.

	Fred.

Pascal Bleser wrote:
> 
> On Fri, Jul 23, 1999 at 04:21:27PM +0200, Alain Spineux wrote:
> > > Les processus sous UNIX, ils ont 2 ou 3 segments ?
> > Il n'y a pas de regle pour les systemes unix !
> > > Je sais bien qu'il y a
> > > - segment "text": le code
> > tu utilises le Code Segment (cs sur i386) si le processeur en a un
> > > - segment "data": les données statiques
> > tu utilises le Data Segment (ds sur i386) si le processeur en a un
> > > mais qu'en est-il du user-stack ?
> > Tu utilises le Stack Segment (cs sur i386) si le processeur en a un
> > Et cela meme si cs==ds==cs
> > > Il est alloué dans le segment data ou bien il a un segment propre ?
> > Je crois que les segments n'existe pas sur Alpha et donc les derniers kernel
> > linux
> > n'utiliserai  plus la segmentation du i386, et donc il n'y aurait plus qu'un
> > seul segment !
> > Ce qui limiterai la mem des process a 3Go, le dernier etant reserve au
> > kernel !
> > LA stack est elle limitee a 8Mo sous linux, je sais pas pourquoi. MAis
> > elle est surement alloue dynamiquement.
> "la" ou "le" stack, y a pas de réponse: c'est the stack en anglais ;))
> Personellement, je préfère "le" stack... et ne me parle pas de "la" pile ;)
> > > Et qqn sait comment Linux g?re le heap permettant l'allocation dynamique
> > > de mémoire ?
> > Dynamiquement ca veux dire quoi ? (je me pose la question)
> Et bien malloc ou new, au lieu d'une variable statique (au sens C, pas C++).
> 
> > Suposons :
> > un process de 1Mo, il malloc 8Mo.
> > Il ne se passe rien, aucune page n'est alloue, rien ne bouge, pas de swap,
> > RIEN
> > sauf que le noyau note qu'il a etendu son espace de 8Mo !
> > Il deference un pointeur, le process regarde
> > a l'adresse et voi qu'il n'y a pas de page allouee ! => SEGFAULT, la le
> Un "page fault", oui... SEGFAULT c'est quand il accède à une page qui ne
> lui est pas allouée. Un page fault, c'est quand il accède à une page qui
> lui est allouée mais qu'elle n'est pas chargée en mémoire (elle est vide
> ou en swap ou sur disque). Ce principe est d'ailleurs aussi bien valable
> pour du code éxécutable: quand tu as un éxécutable de 10MB, ça ne veut
> pas dire que les 10MB sont chargé d'un coup en mémoire. Les pages sont
> chargées une à une, à la demande. Si 2MB de l'éxécutable ne sont jamais
> utilisés (du code pas utilisé, des variables globales non accédées, etc...),
> ils resteront uniquement sur disque et ne seront jamais chargés en
> mémoire.
> 
> > kernel verifie
> > si l'adresse est en dessous de 9Mo du process et si oui alloue  une page a
> > cette adresse,
> > et le process continue. Sinon le pointeur contenait du caca et le process
> > segfault !
> En effet, là, c'est bien un "segfault" ;))
> 
> > Je sais pas si c'est comme ca, mais ca me parait coherent, et econome !
> Oui, tout à fait d'accord, je connais bien le principe du page fault.
> Néanmoins, j'avais dans l'idée que les systèmes UNIX géraient des zones de
> mémoires différentes, l'une dédiée au code, l'autre aux données, mais c'est
> de la big carabistouille apparamment.
> Le principe de la page à la demande est bien clair...
> juste une chose: les pages ont bien des droits d'accès, non (un peu comme
> les fichiers) ? Les pages réservées pour du code sont read/execute, alors
> que les pages pour les donneés sont read/write (uniquement pour le processus
> propriétaire des pages, bien entendu ;)).
> 
> --
>   -o)  Pascal Bleser        | Instead of giving  Windows
>   /\\  C++/UNIX Development | the "three-finger-salute",
>  _\_v  ATOS Payment Systems | give it  the  "one-finger-
>        Aachen, Germany      | goodbye"  {jfk/propaganda}
> <pbleser@atos-group.com>--------------<guru@linuxbe.org>
> 
> ---------
> Visit the Linux Supertore Online: http://www.redcorp.com !
> If you want to be deleted from the list, send a mail to
> majordomo@rtfm.be with "unsubscribe linux-team" in the body.

-- 
------------------------- * oOo * -------------------------
                        CiscoSystems

                  Frederic Detienne, CSE II
                 Security & Network Services

                     Tel 32 2 705 55 55
---------
Visit the Linux Supertore Online: http://www.redcorp.com !
If you want to be deleted from the list, send a mail to
majordomo@rtfm.be with "unsubscribe linux-team" in the body.