[gull] Re : Kubuntu 12.04 LTS x64 et M-BancNet

Daniel Cordey dc at mjt.ch
Fri May 25 14:47:37 CEST 2012


On Fri, May 25, 2012 13:08, Marc Mongenet wrote:

> Ce devait être le cas il y a très longtemps. Vers 1999 peut-être si j'interprète
> bien https://lwn.net/Articles/75174/ ?
>
> En 2004, d'après https://lwn.net/Articles/91829/ c'était une division
> 3 Go user / 1 Go kernel mais avec des sous-divisions inflexibles de
> la zone user (voir les jolis schémas dans l'article).

En fait, c'est plus subtile que ca... Il y a quatre grande regions (segments) dans linux. Chacune a (par defaut sur un systeme 32 bits)
une taille de 1GB. Lorsque l'on a 4 GB de RAM, ca ne veut en tout cas pas dire que l'on peut avoir des programes qui manipulent 3 GB !!!
La premiere region est celle dans laquelle le 'user code' reside; c'est la zone appelee 'TEXT'. L'isolation de cette zone permet de
facilement proteger le code executable contre toute tentative de modification du code executable (contrairement a un autre OS bien connu).
Cette zone est donc en lecture seule. La deuxieme zone de 1 GB (environ...). Elle contient les data du programmes; soite les variables
statiques, les constantes et les resultat de l'execution des malloc(). Cette zone "croit" dans une direction... a la renconre d'une aure
zone utilisee par les mmap (Memory Mapped Files). Cette derniere est utilisee pour les shared librairies (code executable), les 'shared
memory' et les vrais mmap (programmes comme tel). C'est une zone en mode read-write et partageable par tous les process. Sa taille etait
initialement de 1GB, mais elle est plutot variable afin d'accomoder les programmes pour acceder a plus de DATA (2eme segment). Lorsque ces
deux zonees se rencontrent... c'est la fin des haricots :-) Suivant les kernel, le user-stack est soit dans le meme segment que MMAP, soit
MMAP est dans le meme segment que DATA. Il reste un dernier segment qui est le kernel et qui occupe bien, de maniere privee, 1 GB.

Gross-modo, 1 GB pourle kernel, le reste pour le user-space. Dans le user-space, on la la zone de TEXT de 1 GB et le reste (2 GB) est
partage/reparti entre HEAP, STACK et MMAP. ce qui fait que la zone DATA ne peut, dans le meilleyr des cas, pas depasser 2 GB ! En realite,
des que l'on arrive dans la zone d'utilisation de 1.3-1.5 GB on ne peut plus alloue de memoire (malloc()/fork() -> -1). La petite astuce
de PAE est que l'on a rajouer 1 bit (oui un seul) a l'adressage standard 32 bits. Ce bit suplemehtaire est traite en software par le
kernel. Ajoutez des bits d'adressage virtuels suplementaires engendrerait sans doute une surcharge non-negligeable, rendant caduque ce
genre de solution. Il y a un monet ou il faut bien songer a faire le pas en 64 bits :-)

Les divers patch essaient soit d'utiliser differement la limites des 4 segments de 1 GB, soit permettent d'etendre un peu la taille de ces
segments a 2 GB... Ce qui nou donne bien les fameux 8 GB mis a disposition a l'aide de PAE. Ce qui est trompeur est que l'on a simplement
double les limites, mais celles-ci subsistent a un niveau un peu plus eleve. Ce qui fait qu'un kernel 32 bits abec PAE ne permettra pas
d'acceder a beaucoup de DATA que 3 GB...

> Enfin, en 64 bits on s'en fiche un peu de ces bidouilles. :)

Oui... si tu as assez de memoire :-) Je rigole... La limite est dans l'adressage de la memoire virtuelle et les systemes 64 bits on des
limites qui ne nous concernerons pas avant quelques annees (elles ont en theorie ete multipliees par 4 milliards). Les malloc()/fork() ne
vont sans doute plus poser de probleme... mais vous aurez des problemes de performance quand vous commencerz a swaper !

dc


More information about the gull mailing list