[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [linux-team] processus et segments
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.