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 _______________________________________________ gull mailing list [email protected] http://forum.linux-gull.ch/mailman/listinfo/gull
