j'ai quelques machines bi et quadriproc qui tournent avec un linux smp
(uniquement des mandrake 9.2), et j'ai un soucis sur la gestion de la
memoire.
Quand un utilisateur lance un calcul occupant beaucoup de memoire, la
machine n'occupe jamais toute la memoire dispo mais sature sur une
barette (1Go ou 512Mo).
Existe t'il un moyen pour permettre à un processus d'occuper toute la
memoire ?
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.
De toute façon, une architecture 32 bits ne permettra d'addresser que 4 Go. Pour plus de finesse dans les calculs, il faudra passer à 64 bits ou gerer soi même de la mémoire partagées qu'on allouera et désasallouera en fonction des besoins, mais les performances seront médiocres et la programation sera complexe (surtout en Fortran).
Deepthroat <deep@throat.org> écrit:
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.
De toute façon, une architecture 32 bits ne permettra d'addresser que
4 Go. Pour plus de finesse dans les calculs, il faudra passer à 64
bits ou gerer soi même de la mémoire partagées qu'on allouera et
désasallouera en fonction des besoins, mais les performances seront
médiocres et la programation sera complexe (surtout en Fortran).
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.
De toute façon, une architecture 32 bits ne permettra d'addresser que 4 Go. Pour plus de finesse dans les calculs, il faudra passer à 64 bits ou gerer soi même de la mémoire partagées qu'on allouera et désasallouera en fonction des besoins, mais les performances seront médiocres et la programation sera complexe (surtout en Fortran).
Manu
Laurent Wacrenier wrote:
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.
Le problème se situe plus du coté des variables statiques à mon avis. Il faudrait faire un test avec un tableau du style: char tab[1024][1024][1024];
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.
Ici sur la même machine, l'allocation dynamique de 1Go fonctionne alors que le même en statique segfault.
Laurent Wacrenier wrote:
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.
Le problème se situe plus du coté des variables statiques à mon avis.
Il faudrait faire un test avec un tableau du style:
char tab[1024][1024][1024];
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.
Ici sur la même machine, l'allocation dynamique de 1Go fonctionne alors
que le même en statique segfault.
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.
Le problème se situe plus du coté des variables statiques à mon avis. Il faudrait faire un test avec un tableau du style: char tab[1024][1024][1024];
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.
Ici sur la même machine, l'allocation dynamique de 1Go fonctionne alors que le même en statique segfault.
Manu
Deepthroat wrote:
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.
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...
Deepthroat wrote:
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.
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...
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.
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...
Jean-Marc Bourguet
Deepthroat writes:
OK, et quidd du 36bits (j'ai lu ca a plusieurs endroits) ?
Si c'est ce a quoi je pense (et donc pas d'utilisation d'un PDP-10 :-) ca permet d'avoir plus de 4G de memoire pour le processeur, mais un process ne peut en adresser que 4GB.
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Deepthroat <deep@throat.org> writes:
OK, et quidd du 36bits (j'ai lu ca a plusieurs endroits) ?
Si c'est ce a quoi je pense (et donc pas d'utilisation d'un PDP-10 :-)
ca permet d'avoir plus de 4G de memoire pour le processeur, mais un
process ne peut en adresser que 4GB.
A+
--
Jean-Marc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
OK, et quidd du 36bits (j'ai lu ca a plusieurs endroits) ?
Si c'est ce a quoi je pense (et donc pas d'utilisation d'un PDP-10 :-) ca permet d'avoir plus de 4G de memoire pour le processeur, mais un process ne peut en adresser que 4GB.
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Et bien, 1 Go + 1 octet a pu être alloué avec succès.
Oui et non.
A une epoque ou je faisais quelques tests memoire, je m'etais rendu compte que le fait d'allouer un gros bloc de memoire, puis de liberer celle ci et quitter ne faisait pas de "reelle allocation de memoire physique en RAM".
Un effet de bord facile a constater etait que ma consommation de memoire cache etait encore importante juste apres la fin du programme (alors que ca aurait du creer un vide).
J'avais change le binaire pour faire une lecture et/ou ecriture de chaque octet de la zone allouee, et c'est seulement la que j'ai constate une grosse chute d'utilisation memoire juste apres la fin d'execution de ce programme (logique, pour allouer cette memoire *vraiment utilisee*, le systeme purgeait beaucoup de memoire cache).
Et bien, 1 Go + 1 octet a pu être alloué avec succès.
Oui et non.
A une epoque ou je faisais quelques tests memoire, je m'etais rendu
compte que le fait d'allouer un gros bloc de memoire, puis de liberer
celle ci et quitter ne faisait pas de "reelle allocation de memoire
physique en RAM".
Un effet de bord facile a constater etait que ma consommation de
memoire cache etait encore importante juste apres la fin du programme
(alors que ca aurait du creer un vide).
J'avais change le binaire pour faire une lecture et/ou ecriture de
chaque octet de la zone allouee, et c'est seulement la que j'ai
constate une grosse chute d'utilisation memoire juste apres la fin
d'execution de ce programme (logique, pour allouer cette memoire
*vraiment utilisee*, le systeme purgeait beaucoup de memoire cache).
Et bien, 1 Go + 1 octet a pu être alloué avec succès.
Oui et non.
A une epoque ou je faisais quelques tests memoire, je m'etais rendu compte que le fait d'allouer un gros bloc de memoire, puis de liberer celle ci et quitter ne faisait pas de "reelle allocation de memoire physique en RAM".
Un effet de bord facile a constater etait que ma consommation de memoire cache etait encore importante juste apres la fin du programme (alors que ca aurait du creer un vide).
J'avais change le binaire pour faire une lecture et/ou ecriture de chaque octet de la zone allouee, et c'est seulement la que j'ai constate une grosse chute d'utilisation memoire juste apres la fin d'execution de ce programme (logique, pour allouer cette memoire *vraiment utilisee*, le systeme purgeait beaucoup de memoire cache).
A +
VANHU.
Laurent Wacrenier
VANHULLEBUS Yvan écrit:
A une epoque ou je faisais quelques tests memoire, je m'etais rendu compte que le fait d'allouer un gros bloc de memoire, puis de liberer celle ci et quitter ne faisait pas de "reelle allocation de memoire physique en RAM".
L'allocateur ne va pas poker des trucs dans la RAM. La mémoire accessible est la mémoire virtuelle (RAM + swap), de manière transparente. Le système utilise une stratégie pour mettre en RAM ce dont le programme a besoin quand il en a besoin et le remettre en swap quand il ne s'en sert plus.
VANHULLEBUS Yvan <vanhu@nospam_free.fr> écrit:
A une epoque ou je faisais quelques tests memoire, je m'etais rendu
compte que le fait d'allouer un gros bloc de memoire, puis de liberer
celle ci et quitter ne faisait pas de "reelle allocation de memoire
physique en RAM".
L'allocateur ne va pas poker des trucs dans la RAM. La mémoire
accessible est la mémoire virtuelle (RAM + swap), de manière
transparente. Le système utilise une stratégie pour mettre en RAM ce
dont le programme a besoin quand il en a besoin et le remettre en swap
quand il ne s'en sert plus.
A une epoque ou je faisais quelques tests memoire, je m'etais rendu compte que le fait d'allouer un gros bloc de memoire, puis de liberer celle ci et quitter ne faisait pas de "reelle allocation de memoire physique en RAM".
L'allocateur ne va pas poker des trucs dans la RAM. La mémoire accessible est la mémoire virtuelle (RAM + swap), de manière transparente. Le système utilise une stratégie pour mettre en RAM ce dont le programme a besoin quand il en a besoin et le remettre en swap quand il ne s'en sert plus.
VANHULLEBUS Yvan
Laurent Wacrenier <lwa@ teaser . fr> writes:
VANHULLEBUS Yvan écrit:
A une epoque ou je faisais quelques tests memoire, je m'etais rendu compte que le fait d'allouer un gros bloc de memoire, puis de liberer celle ci et quitter ne faisait pas de "reelle allocation de memoire physique en RAM".
L'allocateur ne va pas poker des trucs dans la RAM. La mémoire accessible est la mémoire virtuelle (RAM + swap), de manière transparente. Le système utilise une stratégie pour mettre en RAM ce dont le programme a besoin quand il en a besoin et le remettre en swap quand il ne s'en sert plus.
Yep.
Il n'empeche que faire un gros malloc ne "suffit" pas forcement pour verifier qu'une machine (hard+soft) est capable de manipuler reellement cette quantite de memoire.....
Mais bon, il est probable que le test confirme quand meme que c'est pas ca, c'est surtout que ca me derange pas d'avoir tort, mais seulement quand j'ai raison :-)
A +
VANHU.
Laurent Wacrenier <lwa@ teaser . fr> writes:
VANHULLEBUS Yvan <vanhu@nospam_free.fr> écrit:
A une epoque ou je faisais quelques tests memoire, je m'etais rendu
compte que le fait d'allouer un gros bloc de memoire, puis de liberer
celle ci et quitter ne faisait pas de "reelle allocation de memoire
physique en RAM".
L'allocateur ne va pas poker des trucs dans la RAM. La mémoire
accessible est la mémoire virtuelle (RAM + swap), de manière
transparente. Le système utilise une stratégie pour mettre en RAM ce
dont le programme a besoin quand il en a besoin et le remettre en swap
quand il ne s'en sert plus.
Yep.
Il n'empeche que faire un gros malloc ne "suffit" pas forcement pour
verifier qu'une machine (hard+soft) est capable de manipuler
reellement cette quantite de memoire.....
Mais bon, il est probable que le test confirme quand meme que c'est
pas ca, c'est surtout que ca me derange pas d'avoir tort, mais
seulement quand j'ai raison :-)
A une epoque ou je faisais quelques tests memoire, je m'etais rendu compte que le fait d'allouer un gros bloc de memoire, puis de liberer celle ci et quitter ne faisait pas de "reelle allocation de memoire physique en RAM".
L'allocateur ne va pas poker des trucs dans la RAM. La mémoire accessible est la mémoire virtuelle (RAM + swap), de manière transparente. Le système utilise une stratégie pour mettre en RAM ce dont le programme a besoin quand il en a besoin et le remettre en swap quand il ne s'en sert plus.
Yep.
Il n'empeche que faire un gros malloc ne "suffit" pas forcement pour verifier qu'une machine (hard+soft) est capable de manipuler reellement cette quantite de memoire.....
Mais bon, il est probable que le test confirme quand meme que c'est pas ca, c'est surtout que ca me derange pas d'avoir tort, mais seulement quand j'ai raison :-)
A +
VANHU.
manu
JKB wrote:
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...
Oh, les trucs mal programmés, c'est pourtant pas ca qui manque...
-- Emmanuel Dreyfus Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
JKB <knatschke@koenigsberg.fr> wrote:
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...
Oh, les trucs mal programmés, c'est pourtant pas ca qui manque...
--
Emmanuel Dreyfus
Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies
http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
manu@netbsd.org
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...
Oh, les trucs mal programmés, c'est pourtant pas ca qui manque...
-- Emmanuel Dreyfus Le cahier de l'admin BSD 2eme ed. est dans toutes les bonnes librairies http://www.eyrolles.com/Informatique/Livre/9782212114638/livre-bsd.php
JKB
Le 23-03-2005, à propos de Re: Gestion memoire sur une machine bi/quadriproc, Emmanuel Dreyfus écrivait dans fr.comp.os.unix :
JKB wrote:
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...
Oh, les trucs mal programmés, c'est pourtant pas ca qui manque...
Disons que j'ai déjà programmé des trucs en Fortran et mémoire statique comme un goret faute de temps, et un giga, je trouve que cela commence à faire beaucoup (pourtant, en traitement du signal...).
JKB
-- En plus c'est simple, je fais ce genre de trucs en g77 depuis des années : il suffit d'écrire un wrapper en C. Et comme ça, j'ai le meilleur des deux mondes : la rigueur quasi-monacale du Fortran, et l'exubérance pétulante du C.
Le 23-03-2005, à propos de
Re: Gestion memoire sur une machine bi/quadriproc,
Emmanuel Dreyfus écrivait dans fr.comp.os.unix :
JKB <knatschke@koenigsberg.fr> wrote:
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...
Oh, les trucs mal programmés, c'est pourtant pas ca qui manque...
Disons que j'ai déjà programmé des trucs en Fortran et mémoire
statique comme un goret faute de temps, et un giga, je trouve que
cela commence à faire beaucoup (pourtant, en traitement du
signal...).
JKB
--
En plus c'est simple, je fais ce genre de trucs en g77 depuis des années :
il suffit d'écrire un wrapper en C. Et comme ça, j'ai le meilleur des deux
mondes : la rigueur quasi-monacale du Fortran, et l'exubérance pétulante du C.
Le 23-03-2005, à propos de Re: Gestion memoire sur une machine bi/quadriproc, Emmanuel Dreyfus écrivait dans fr.comp.os.unix :
JKB wrote:
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...
Oh, les trucs mal programmés, c'est pourtant pas ca qui manque...
Disons que j'ai déjà programmé des trucs en Fortran et mémoire statique comme un goret faute de temps, et un giga, je trouve que cela commence à faire beaucoup (pourtant, en traitement du signal...).
JKB
-- En plus c'est simple, je fais ce genre de trucs en g77 depuis des années : il suffit d'écrire un wrapper en C. Et comme ça, j'ai le meilleur des deux mondes : la rigueur quasi-monacale du Fortran, et l'exubérance pétulante du C.
Deepthroat
Oh, les trucs mal programmés, c'est pourtant pas ca qui manque...
Ce ne sont pas des 'hello world'. Les gens avec qui je travaille ne peuvent alleger leur code, ni les resultats. Faut savoir qu'en mecaflu, que ce soit de la simulation numerique ou de la PIV, les outils informatiques utilisés ont tout de suite besoin d'etre enormes. (genre une manip de PIV sur 2 Jours qui genere 3To de fichier)
Oh, les trucs mal programmés, c'est pourtant pas ca qui manque...
Ce ne sont pas des 'hello world'. Les gens avec qui je travaille ne
peuvent alleger leur code, ni les resultats. Faut savoir qu'en mecaflu,
que ce soit de la simulation numerique ou de la PIV, les outils
informatiques utilisés ont tout de suite besoin d'etre enormes. (genre
une manip de PIV sur 2 Jours qui genere 3To de fichier)
Oh, les trucs mal programmés, c'est pourtant pas ca qui manque...
Ce ne sont pas des 'hello world'. Les gens avec qui je travaille ne peuvent alleger leur code, ni les resultats. Faut savoir qu'en mecaflu, que ce soit de la simulation numerique ou de la PIV, les outils informatiques utilisés ont tout de suite besoin d'etre enormes. (genre une manip de PIV sur 2 Jours qui genere 3To de fichier)
