Gestion memoire sur une machine bi/quadriproc

Sans vouloir être indiscret, pourquoi c'est si gros ???

Ce sont des applications de calculs de mecanique des fluides sur des
volumes prealablement maillés.

( Tue, 22 Mar 2005 19:07:48 +0000 ) JKB :

Le 22-03-2005, à propos de
Re: Gestion memoire sur une machine bi/quadriproc,
Deepthroat écrivait dans fr.comp.os.unix :

C'est l'executable qui fait des Giga ou la mémoire alloué ?

C'est l'executable en lui meme qui fait plus d'un Go, celui dont j'ai
parlé plus haut fait dans les 2Go.

Si ce n'est pas indiscret, que fait le programme en question, parce
j'ai du mal à imaginer un exécutable de plus d'un giga...

[Fu2 la buvette]

Un progremme qui affiche l'alpahbet chinois ? ou japonnais ?

--
Les serveurs avec 10Mb/s se louent maintenant pour 50 ou 60 Euros par mois!
La preuve http://www.google.fr/search?q=serveur+dedie
Infogerance de serveur dedie http://aspo.rktmb.org/activites/infogerance
(En louant les services de l'ASPO vous luttez contre la fracture numerique)

Deepthroat <deep@throat.org> écrit:

C'est l'executable qui fait des Giga ou la mémoire alloué ?

C'est l'executable en lui meme qui fait plus d'un Go, celui dont j'ai
parlé plus haut fait dans les 2Go.

hmm... que donne les commandes "size" et "ldd" sur l'executable en
question ?

Si une partie "text" ou "data" dépasse la taille limite de ce que peut
gérer mmap(2), possible que tout ne rentre pas en mémoire.

Que donne ce programe, une fois compilé ?

#include <stdlib.h>
#include <stdio.h>
void main(void) {
void *x = mallloc(1024 * 1024 * 1024 + 1)
printf("x=%pn", x);
}

[vincent@gandalf tmp]# ./a.out
x=0x40158008

Et bien, 1 Go + 1 octet a pu être alloué avec succès.

Deepthroat <deep@throat.org> écrit:

C'est l'executable qui fait des Giga ou la mémoire alloué ?

C'est l'executable en lui meme qui fait plus d'un Go, celui dont j'ai
parlé plus haut fait dans les 2Go.

hmm... que donne les commandes "size" et "ldd" sur l'executable en
question ?

Si une partie "text" ou "data" dépasse la taille limite de ce que peut
gérer mmap(2), possible que tout ne rentre pas en mémoire.

Que donne ce programe, une fois compilé ?

#include <stdlib.h>
#include <stdio.h>
void main(void) {
void *x = mallloc(1024 * 1024 * 1024 + 1)
printf("x=%pn", x);
}

[vincent@gandalf tmp]# ./a.out
x=0x40158008

Et bien, 1 Go + 1 octet a pu être alloué avec succès.

Apparement, l'allocateur dynamique pose ses pointeurs autour
de 0x40000000 (1 Go), possible que le système ne puisse gérer
des segments plus gros.

Deepthroat <deep@throat.org> écrit:

Ce sont des applications de calculs de mecanique des fluides sur des
volumes prealablement maillés.

Le programme est linéarisé (pour éviter les boucles sur les mailles et
gagner du temps) ou quoi ?

Quoi qu'il en soit, sur une architecture 32 bits, la mémoire
adressable n'est que de 4 Go. Vu qu'il y a plusieurs segments dans un
programme et que le système peut utiliser certaines valeurs, des
problèmes peuvent survenir au delà du Go (souvent 2 Go).

Pour celà, il faut soit concevoir le programme autrement (pour qu'il
prenne moins de taille ou ai des segments plus petits) ou utiliser une
architecture 64 bits.

Par exemple, si le programme utilise des flotants double précision
(double en C), en passant en simple précision (float en C), on peut
gagner pas mal de place.

Je suis prêt à parier que le programme en question est écrit en Fortran
et il me semble qu'en Fortran tout est en statique.

C'est du fortran oui.

Deepthroat wrote:

Par contre le limite à 1Go de est curieuse. Regarde du coté de la
sécurité du système et des limitations.

Le truc , c'est que j'ai toujours cette limite :

Un quadipro (PIII) avec 4Go de RAM -> la limite que l'on a pu voir etai t
de 1Go par processus.

Un bipro (Xeon) avec 2Go -> limite egalement de 1Go par processus.

Les options du noyaux semblent bonnes et ulimit ne limite rien.

desole, pas e web hier, je suis de retour dans le thread.
apparemment des elements de reponse ont ete apporte.

effectivement sous linux processus ne peux pas avoir plus de 2go de memoi re
adressee (sauf 3 Go si certain patch kernel de suse, peux recommandable a cause
d effet de bord indesirable.)

si tu q un blocage a 1go il doit y avoir un probleme ailleur.

question bete a 2 sous, es tu sur que la machine voit bien les 4go physiq ues?

peut tu nous dire a quel taille tes process partent en core?

sinon tu a quel version du kernel ?
les parametres de VM sont ceux par defaut ou parametres maison?

Le programme est linéarisé (pour éviter les boucles sur les mailles et
gagner du temps) ou quoi ?

J'avoue que je connais pas tres bien l'archi de l'executable, mais ca
semble tres verouillé car gere par l'usine a gaz de mecaflu 'Star-CD'
qui compile en fortran avec le compilo AB Soft. En tant qu'utilisateur
on a pas forcement acces a l'archi du programme.

Quoi qu'il en soit, sur une architecture 32 bits, la mémoire
adressable n'est que de 4 Go. Vu qu'il y a plusieurs segments dans un
programme et que le système peut utiliser certaines valeurs, des
problèmes peuvent survenir au delà du Go (souvent 2 Go).

OK, et quidd du 36bits (j'ai lu ca a plusieurs endroits) ?

Pour celà, il faut soit concevoir le programme autrement (pour qu'il
prenne moins de taille ou ai des segments plus petits) ou utiliser une
architecture 64 bits.

Pas de 64bits chez nous.
En fait nos equipes ont des acces a des centres de calculs mais pour
depanner et diversent raisons, certaines machines multiproc sont utiles
en local, mais elles ne sont pas suffisemment optimisées apparemment.

Par exemple, si le programme utilise des flotants double précision
(double en C), en passant en simple précision (float en C), on peut
gagner pas mal de place.

D'un point de vu scientifique, je crois que les utilisateurs preferent
les doubles precisions

effectivement sous linux processus ne peux pas avoir plus de 2go de
memoire adressee (sauf 3 Go si certain patch kernel de suse, peux
recommandable a cause d effet de bord indesirable.)

si tu q un blocage a 1go il doit y avoir un probleme ailleur.

question bete a 2 sous, es tu sur que la machine voit bien les 4go
physiques?

Oui les machines voient bien l'integralite de leur RAM.

J'ai essayé un truc ce matin et ca semble marcher en l'attente de tests
plus poussés.

J'ai lu qu'en modifiant

#define TASK_UNMAPPED_BASE (TASK_SIZE / 3) dans
/usr/src/linux/include/asm/processor.h par
#define TASK_UNMAPPED_BASE (TASK_SIZE / 3 * 2)
on pouvait multiplier la memory limit per process.

Noyau recompile, boot impeccable, et au premier test, l'executable qui
segfaultait hier, ne segfault plus aujourd'hui.

Alors je ne suis pas un expert, loin de la, et je ne sais pas si cette
modif est une solution viable, mais aux premiers abords, ca semblent
fonctionner.

Manu <nobody@guzu.net> écrit:

Il semblerait que se soit un bug du chargeur Linux et que en compilant
en statique (option -s ou -static) cela passe.
Je confirme la chose sur du code C...

Un lien qui parle succintement de ça pour le Fortran d'IBM pour Linux,
mais qui semble généralisable à Linux :

http://support.intel.com/support/performancetools/fortran/linux/sb/CS-007795.htm

Lier statiquement permet d'éviter d'avoir des librairies qui trainent
au milieu du segment de bss (données statiques non initialisées).