This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA97B4EC9B27243FF723CC6C3
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Salut à tous,
Je fais un petit programme censé tester un point précis de la gestion de la
mémoire sous Linux. J'essaie de déclencher des segfault en écrivant ds la
mémoire octet par octet à partir d'un endroit que j'ai alloué.
Comme il me semble qu'une page fait généralement 4ko sous mon os préféré. Le
nombre d'octets au bout duquel j'obtiens une segfault ne devrait jamais dépasser
4096, non ? (voire 8192 avec des pages de 8ko).
Or le nombre est bcp plus gd que ça : 137400. Soit j'ai fait une connerie ds les
15 lignes que j'ai écrites (honte sur moi) soit je comprends plus...
Y a-t-il un moyen de connaitre la taille des pages que le noyau en cours
d'utilisation va utiliser ? (quelque part dans /proc j'imagine).
D'avance merci.
--
Baptiste <Batmat> Mathus
Baptiste at Mathus point org
http://www.batmat.net
OpenPGP : 0xE8EC628F
---------
Si chacun de nous a une idée et que nous les partageons, nous repartirons
tous les deux avec deux idées... C'est ça le Libre.
Le Sun, Dec 12, 2004 at 10:54:57PM +0100, Baptiste Mathus ecrit :
Salut à tous, Je fais un petit programme censé tester un point précis de la gestion de la mémoire sous Linux. J'essaie de déclencher des segfault en écrivant ds la mémoire octet par octet à partir d'un endroit que j'ai alloué. Comme il me semble qu'une page fait généralement 4ko sous mon os préféré. Le nombre d'octets au bout duquel j'obtiens une segfault ne devrait jamais dépasser 4096, non ? (voire 8192 avec des pages de 8ko). Or le nombre est bcp plus gd que ça : 137400. Soit j'ai fait une connerie ds les 15 lignes que j'ai écrites (honte sur moi) soit je comprends plus...
[...]
Y a-t-il un moyen de connaitre la taille des pages que le noyau en cours d'utilisation va utiliser ? (quelque part dans /proc j'imagine).
---end quoted text / fin de citation---
Salut, Je n'ai pas de réponse à ta question, juste le résultat de ton programme sur mon systeme : :~$ ./test segfault attrapée : j = 135160
Ce qui confirme tes résultats sur un noyau Linux oceane 2.6.8-1-k7 #1 Thu Oct 7 02:47:47 EDT 2004 i686 GNU/Linux dans une installation Debian. Je n'ai pas le courage de redémarrer sur mon LFS en 2.6.8 aussi, mais je suppose que, même avec un noyau pur, le résultat sera le même.
A+ Fanfan -- Soyons reconnaissants aux personnes qui nous donnent du bonheur ; elles sont les charmants jardiniers par qui nos âmes sont fleuries. [Marcel Proust]
--LZvS9be/3tNcYl/X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline
Le Sun, Dec 12, 2004 at 10:54:57PM +0100, Baptiste Mathus ecrit :
Salut à tous,
Je fais un petit programme censé tester un point précis de la
gestion de la mémoire sous Linux. J'essaie de déclencher des
segfault en écrivant ds la mémoire octet par octet à partir d'un
endroit que j'ai alloué.
Comme il me semble qu'une page fait généralement 4ko sous mon os
préféré. Le nombre d'octets au bout duquel j'obtiens une segfault
ne devrait jamais dépasser 4096, non ? (voire 8192 avec des pages de
8ko).
Or le nombre est bcp plus gd que ça : 137400. Soit j'ai fait une
connerie ds les 15 lignes que j'ai écrites (honte sur moi) soit je
comprends plus...
[...]
Y a-t-il un moyen de connaitre la taille des pages que le noyau en
cours d'utilisation va utiliser ? (quelque part dans /proc
j'imagine).
---end quoted text / fin de citation---
Salut,
Je n'ai pas de réponse à ta question, juste le résultat de ton
programme sur mon systeme :
fcerbell@oceane:~$ ./test
segfault attrapée : j = 135160
Ce qui confirme tes résultats sur un noyau
Linux oceane 2.6.8-1-k7 #1 Thu Oct 7 02:47:47 EDT 2004 i686 GNU/Linux
dans une installation Debian. Je n'ai pas le courage de redémarrer sur
mon LFS en 2.6.8 aussi, mais je suppose que, même avec un noyau pur,
le résultat sera le même.
A+
Fanfan
--
Soyons reconnaissants aux personnes qui nous donnent du bonheur ;
elles sont les charmants jardiniers par qui nos âmes sont fleuries.
[Marcel Proust]
--LZvS9be/3tNcYl/X
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
Le Sun, Dec 12, 2004 at 10:54:57PM +0100, Baptiste Mathus ecrit :
Salut à tous, Je fais un petit programme censé tester un point précis de la gestion de la mémoire sous Linux. J'essaie de déclencher des segfault en écrivant ds la mémoire octet par octet à partir d'un endroit que j'ai alloué. Comme il me semble qu'une page fait généralement 4ko sous mon os préféré. Le nombre d'octets au bout duquel j'obtiens une segfault ne devrait jamais dépasser 4096, non ? (voire 8192 avec des pages de 8ko). Or le nombre est bcp plus gd que ça : 137400. Soit j'ai fait une connerie ds les 15 lignes que j'ai écrites (honte sur moi) soit je comprends plus...
[...]
Y a-t-il un moyen de connaitre la taille des pages que le noyau en cours d'utilisation va utiliser ? (quelque part dans /proc j'imagine).
---end quoted text / fin de citation---
Salut, Je n'ai pas de réponse à ta question, juste le résultat de ton programme sur mon systeme : :~$ ./test segfault attrapée : j = 135160
Ce qui confirme tes résultats sur un noyau Linux oceane 2.6.8-1-k7 #1 Thu Oct 7 02:47:47 EDT 2004 i686 GNU/Linux dans une installation Debian. Je n'ai pas le courage de redémarrer sur mon LFS en 2.6.8 aussi, mais je suppose que, même avec un noyau pur, le résultat sera le même.
A+ Fanfan -- Soyons reconnaissants aux personnes qui nous donnent du bonheur ; elles sont les charmants jardiniers par qui nos âmes sont fleuries. [Marcel Proust]
--LZvS9be/3tNcYl/X Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline
Dans sa prose du dimanche 12 décembre de l'an de grâce 2004 à 22h54, Baptiste Mathus s'exprimait ainsi:
Salut à tous,
Je fais un petit programme censé tester un point précis de la gestion de la mémoire sous Linux. J'essaie de déclencher des segfault en écriv ant ds la mémoire octet par octet à partir d'un endroit que j'ai alloué.
Comme il me semble qu'une page fait généralement 4ko sous mon os préféré. Le nombre d'octets au bout duquel j'obtiens une segfault n e devrait jamais dépasser 4096, non ? (voire 8192 avec des pages de 8ko).
Or le nombre est bcp plus gd que ça : 137400. Soit j'ai fait une conner ie ds les 15 lignes que j'ai écrites (honte sur moi) soit je comprends plu s...
Je confirme (plus ou moins) - sous Linux: $ ./segfault segfault attrapée : j = 135160
Donc linux a alloué 33 pages (avec un entête de 8 octets) OpenBSD a alloué 1 page (avec entête de 48 octets)
Je suppose que Linux "optimise" les requêtes en fonction de la mémoire disponible et de la gourmandise de l'application (reste à vérifier) Celà se passe ou au niveau du noyau, ou au niveau de la libc.
JC
--xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline
Dans sa prose du dimanche 12 décembre de l'an de grâce 2004 à 22h54, Baptiste Mathus s'exprimait ainsi:
Salut à tous,
Je fais un petit programme censé tester un point précis de la gestion de
la mémoire sous Linux. J'essaie de déclencher des segfault en écriv ant
ds la mémoire octet par octet à partir d'un endroit que j'ai alloué.
Comme il me semble qu'une page fait généralement 4ko sous mon os
préféré. Le nombre d'octets au bout duquel j'obtiens une segfault n e
devrait jamais dépasser 4096, non ? (voire 8192 avec des pages de 8ko).
Or le nombre est bcp plus gd que ça : 137400. Soit j'ai fait une conner ie
ds les 15 lignes que j'ai écrites (honte sur moi) soit je comprends plu s...
Je confirme (plus ou moins)
- sous Linux:
$ ./segfault
segfault attrapée : j = 135160
Donc linux a alloué 33 pages (avec un entête de 8 octets)
OpenBSD a alloué 1 page (avec entête de 48 octets)
Je suppose que Linux "optimise" les requêtes en fonction de la mémoire
disponible et de la gourmandise de l'application (reste à vérifier)
Celà se passe ou au niveau du noyau, ou au niveau de la libc.
JC
--xHFwDpU9dbj6ez1V
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
Dans sa prose du dimanche 12 décembre de l'an de grâce 2004 à 22h54, Baptiste Mathus s'exprimait ainsi:
Salut à tous,
Je fais un petit programme censé tester un point précis de la gestion de la mémoire sous Linux. J'essaie de déclencher des segfault en écriv ant ds la mémoire octet par octet à partir d'un endroit que j'ai alloué.
Comme il me semble qu'une page fait généralement 4ko sous mon os préféré. Le nombre d'octets au bout duquel j'obtiens une segfault n e devrait jamais dépasser 4096, non ? (voire 8192 avec des pages de 8ko).
Or le nombre est bcp plus gd que ça : 137400. Soit j'ai fait une conner ie ds les 15 lignes que j'ai écrites (honte sur moi) soit je comprends plu s...
Je confirme (plus ou moins) - sous Linux: $ ./segfault segfault attrapée : j = 135160
Donc linux a alloué 33 pages (avec un entête de 8 octets) OpenBSD a alloué 1 page (avec entête de 48 octets)
Je suppose que Linux "optimise" les requêtes en fonction de la mémoire disponible et de la gourmandise de l'application (reste à vérifier) Celà se passe ou au niveau du noyau, ou au niveau de la libc.
JC
--xHFwDpU9dbj6ez1V Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Baptiste Mathus
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB7E448B9877979DA48744FBC Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit
Francois Cerbelle a écrit :
Le Sun, Dec 12, 2004 at 10:54:57PM +0100, Baptiste Mathus ecrit :
Salut à tous, Je fais un petit programme censé tester un point précis de la gestion de la mémoire sous Linux. J'essaie de déclencher des segfault en écrivant ds la mémoire octet par octet à partir d'un endroit que j'ai alloué. Comme il me semble qu'une page fait généralement 4ko sous mon os préféré. Le nombre d'octets au bout duquel j'obtiens une segfault ne devrait jamais dépasser 4096, non ? (voire 8192 avec des pages de 8ko). Or le nombre est bcp plus gd que ça : 137400. Soit j'ai fait une connerie ds les 15 lignes que j'ai écrites (honte sur moi) soit je comprends plus...
[...]
Y a-t-il un moyen de connaitre la taille des pages que le noyau en cours d'utilisation va utiliser ? (quelque part dans /proc j'imagine).
---end quoted text / fin de citation---
Salut, Je n'ai pas de réponse à ta question, juste le résultat de ton programme sur mon systeme : :~$ ./test segfault attrapée : j = 135160
Ce qui confirme tes résultats sur un noyau Linux oceane 2.6.8-1-k7 #1 Thu Oct 7 02:47:47 EDT 2004 i686 GNU/Linux dans une installation Debian. Je n'ai pas le courage de redémarrer sur mon LFS en 2.6.8 aussi, mais je suppose que, même avec un noyau pur, le résultat sera le même.
Merci. Bon, alors j'ai vraiment pas compris la gestion de la mémoire alors... Par contre, je me suis pas trompé :
#include <stdio.h> #include <unistd.h> int main(void) { int page_size = getpagesize(); printf("Taille d'une page du système = %dn", page_size); return 0; }
ça affiche bien 4096... Alors franchement, les quelques 135000 octets avant d'avoir une erreur me laissent perplexe :/
@++
-- Baptiste <Batmat> Mathus Baptiste at Mathus point org http://www.batmat.net OpenPGP : 0xE8EC628F --------- Si chacun de nous a une idée et que nous les partageons, nous repartirons tous les deux avec deux idées... C'est ça le Libre.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigB7E448B9877979DA48744FBC
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Francois Cerbelle a écrit :
Le Sun, Dec 12, 2004 at 10:54:57PM +0100, Baptiste Mathus ecrit :
Salut à tous,
Je fais un petit programme censé tester un point précis de la
gestion de la mémoire sous Linux. J'essaie de déclencher des
segfault en écrivant ds la mémoire octet par octet à partir d'un
endroit que j'ai alloué.
Comme il me semble qu'une page fait généralement 4ko sous mon os
préféré. Le nombre d'octets au bout duquel j'obtiens une segfault
ne devrait jamais dépasser 4096, non ? (voire 8192 avec des pages de
8ko).
Or le nombre est bcp plus gd que ça : 137400. Soit j'ai fait une
connerie ds les 15 lignes que j'ai écrites (honte sur moi) soit je
comprends plus...
[...]
Y a-t-il un moyen de connaitre la taille des pages que le noyau en
cours d'utilisation va utiliser ? (quelque part dans /proc
j'imagine).
---end quoted text / fin de citation---
Salut,
Je n'ai pas de réponse à ta question, juste le résultat de ton
programme sur mon systeme :
fcerbell@oceane:~$ ./test
segfault attrapée : j = 135160
Ce qui confirme tes résultats sur un noyau
Linux oceane 2.6.8-1-k7 #1 Thu Oct 7 02:47:47 EDT 2004 i686 GNU/Linux
dans une installation Debian. Je n'ai pas le courage de redémarrer sur
mon LFS en 2.6.8 aussi, mais je suppose que, même avec un noyau pur,
le résultat sera le même.
Merci.
Bon, alors j'ai vraiment pas compris la gestion de la mémoire alors...
Par contre, je me suis pas trompé :
#include <stdio.h>
#include <unistd.h>
int main(void)
{
int page_size = getpagesize();
printf("Taille d'une page du système = %dn", page_size);
return 0;
}
ça affiche bien 4096... Alors franchement, les quelques 135000 octets avant
d'avoir une erreur me laissent perplexe :/
@++
--
Baptiste <Batmat> Mathus
Baptiste at Mathus point org
http://www.batmat.net
OpenPGP : 0xE8EC628F
---------
Si chacun de nous a une idée et que nous les partageons, nous repartirons
tous les deux avec deux idées... C'est ça le Libre.
This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigB7E448B9877979DA48744FBC Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit
Francois Cerbelle a écrit :
Le Sun, Dec 12, 2004 at 10:54:57PM +0100, Baptiste Mathus ecrit :
Salut à tous, Je fais un petit programme censé tester un point précis de la gestion de la mémoire sous Linux. J'essaie de déclencher des segfault en écrivant ds la mémoire octet par octet à partir d'un endroit que j'ai alloué. Comme il me semble qu'une page fait généralement 4ko sous mon os préféré. Le nombre d'octets au bout duquel j'obtiens une segfault ne devrait jamais dépasser 4096, non ? (voire 8192 avec des pages de 8ko). Or le nombre est bcp plus gd que ça : 137400. Soit j'ai fait une connerie ds les 15 lignes que j'ai écrites (honte sur moi) soit je comprends plus...
[...]
Y a-t-il un moyen de connaitre la taille des pages que le noyau en cours d'utilisation va utiliser ? (quelque part dans /proc j'imagine).
---end quoted text / fin de citation---
Salut, Je n'ai pas de réponse à ta question, juste le résultat de ton programme sur mon systeme : :~$ ./test segfault attrapée : j = 135160
Ce qui confirme tes résultats sur un noyau Linux oceane 2.6.8-1-k7 #1 Thu Oct 7 02:47:47 EDT 2004 i686 GNU/Linux dans une installation Debian. Je n'ai pas le courage de redémarrer sur mon LFS en 2.6.8 aussi, mais je suppose que, même avec un noyau pur, le résultat sera le même.
Merci. Bon, alors j'ai vraiment pas compris la gestion de la mémoire alors... Par contre, je me suis pas trompé :
#include <stdio.h> #include <unistd.h> int main(void) { int page_size = getpagesize(); printf("Taille d'une page du système = %dn", page_size); return 0; }
ça affiche bien 4096... Alors franchement, les quelques 135000 octets avant d'avoir une erreur me laissent perplexe :/
@++
-- Baptiste <Batmat> Mathus Baptiste at Mathus point org http://www.batmat.net OpenPGP : 0xE8EC628F --------- Si chacun de nous a une idée et que nous les partageons, nous repartirons tous les deux avec deux idées... C'est ça le Libre.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Yves Rutschle
On Sun, Dec 12, 2004 at 10:54:57PM +0100, Baptiste Mathus wrote:
Je fais un petit programme censé tester un point précis de la gestion de la mémoire sous Linux. J'essaie de déclencher des segfault en écrivant ds la mémoire octet par octet à partir d'un endroit que j'ai alloué.
Si tu veux regarder ce que fait le noyau, il vaut mieux utiliser directement les appels systèmes (section 2 du manuel): malloc est une fonction de la libc, et tu ne sais pas ce que la libc fait. L'autre chose à regarder est bien entendu les sources.
Comme il me semble qu'une page fait généralement 4ko sous mon os préféré.
Ça dépend en fait de l'architecture, c'est 4Ko en i386 effectivement.
Y a-t-il un moyen de connaitre la taille des pages que le noyau en cours d'utilisation va utiliser ? (quelque part dans /proc j'imagine).
Dans les sources, au début de include/asm/page.h. Dans /proc, je ne sais pas.
En compilant ton programme avec uclibc, on trouve ce à quoi tu t'attends. Donc, glibc bien fait des choses dans ton dos:
Je suppose que glibc pense que c'est malin de pré-attribuer plein de mémoire vue que Linux ne l'attribue pas tant qu'elle n'est pas utilisée (ça économise des appels systèmes).
Y.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
On Sun, Dec 12, 2004 at 10:54:57PM +0100, Baptiste Mathus wrote:
Je fais un petit programme censé tester un point précis de la gestion de la
mémoire sous Linux. J'essaie de déclencher des segfault en écrivant ds la
mémoire octet par octet à partir d'un endroit que j'ai alloué.
Si tu veux regarder ce que fait le noyau, il vaut mieux
utiliser directement les appels systèmes (section 2 du
manuel): malloc est une fonction de la libc, et tu ne sais
pas ce que la libc fait. L'autre chose à regarder est bien
entendu les sources.
Comme il me semble qu'une page fait généralement 4ko sous mon os préféré.
Ça dépend en fait de l'architecture, c'est 4Ko en i386
effectivement.
Y a-t-il un moyen de connaitre la taille des pages que le noyau en cours
d'utilisation va utiliser ? (quelque part dans /proc j'imagine).
Dans les sources, au début de include/asm/page.h. Dans
/proc, je ne sais pas.
En compilant ton programme avec uclibc, on trouve ce à quoi
tu t'attends. Donc, glibc bien fait des choses dans ton dos:
Je suppose que glibc pense que c'est malin de pré-attribuer
plein de mémoire vue que Linux ne l'attribue pas tant
qu'elle n'est pas utilisée (ça économise des appels
systèmes).
Y.
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
On Sun, Dec 12, 2004 at 10:54:57PM +0100, Baptiste Mathus wrote:
Je fais un petit programme censé tester un point précis de la gestion de la mémoire sous Linux. J'essaie de déclencher des segfault en écrivant ds la mémoire octet par octet à partir d'un endroit que j'ai alloué.
Si tu veux regarder ce que fait le noyau, il vaut mieux utiliser directement les appels systèmes (section 2 du manuel): malloc est une fonction de la libc, et tu ne sais pas ce que la libc fait. L'autre chose à regarder est bien entendu les sources.
Comme il me semble qu'une page fait généralement 4ko sous mon os préféré.
Ça dépend en fait de l'architecture, c'est 4Ko en i386 effectivement.
Y a-t-il un moyen de connaitre la taille des pages que le noyau en cours d'utilisation va utiliser ? (quelque part dans /proc j'imagine).
Dans les sources, au début de include/asm/page.h. Dans /proc, je ne sais pas.
En compilant ton programme avec uclibc, on trouve ce à quoi tu t'attends. Donc, glibc bien fait des choses dans ton dos:
Je suppose que glibc pense que c'est malin de pré-attribuer plein de mémoire vue que Linux ne l'attribue pas tant qu'elle n'est pas utilisée (ça économise des appels systèmes).
Y.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Le Mon, Dec 13, 2004 at 01:13:05AM +0100, Jean-Charles Salzeber ecrit :
Je suppose que Linux "optimise" les requêtes en fonction de la mémoire disponible et de la gourmandise de l'application (reste à vérifier) Celà se passe ou au niveau du noyau, ou au niveau de la libc.
---end quoted text / fin de citation---
J'ai pas le temps aujourd'hui, mais "strace" pourrait peut-etre lever le doute sur le responsable de ce comportement etrange.
Fanfan -- - Le pastis se trouble quand on le mouille. Les filles, c'est l'inverse... [Dicton Breton]
--t0UkRYy7tHLRMCai Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline
Le Mon, Dec 13, 2004 at 01:13:05AM +0100, Jean-Charles Salzeber ecrit :
Je suppose que Linux "optimise" les requêtes en fonction de la mémoire
disponible et de la gourmandise de l'application (reste à vérifier)
Celà se passe ou au niveau du noyau, ou au niveau de la libc.
---end quoted text / fin de citation---
J'ai pas le temps aujourd'hui, mais "strace" pourrait peut-etre lever
le doute sur le responsable de ce comportement etrange.
Fanfan
--
- Le pastis se trouble quand on le mouille. Les filles, c'est
l'inverse...
[Dicton Breton]
--t0UkRYy7tHLRMCai
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline
Le Mon, Dec 13, 2004 at 01:13:05AM +0100, Jean-Charles Salzeber ecrit :
Je suppose que Linux "optimise" les requêtes en fonction de la mémoire disponible et de la gourmandise de l'application (reste à vérifier) Celà se passe ou au niveau du noyau, ou au niveau de la libc.
---end quoted text / fin de citation---
J'ai pas le temps aujourd'hui, mais "strace" pourrait peut-etre lever le doute sur le responsable de ce comportement etrange.
Fanfan -- - Le pastis se trouble quand on le mouille. Les filles, c'est l'inverse... [Dicton Breton]
--t0UkRYy7tHLRMCai Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Stephane Bortzmeyer
On Mon, Dec 13, 2004 at 01:14:35AM +0100, Baptiste Mathus wrote a message of 94 lines which said:
ça affiche bien 4096... Alors franchement, les quelques 135000 octets avant d'avoir une erreur me laissent perplexe :/
L'appel système d'allocation de mémoire se nomme brk(2). malloc(3) est un sous-programme qui tourne en mode utilisateur pour rendre plus conviviale l'allocation mémoire. Il demande en général bien plus de mémoire que ce qu'a réclamé le programmeur, pour la distribuer ensuite à loisir (alors que brk, de plus bas niveau, alloue exactement ce qui est demandé).
Le comportement que vous observez est donc parfaitement normal.
Cf. les sources de la GNU libc, répertoire "malloc/" ou bien http://www.malloc.de/en/index.html.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
On Mon, Dec 13, 2004 at 01:14:35AM +0100,
Baptiste Mathus <bmathus@free.fr> wrote
a message of 94 lines which said:
ça affiche bien 4096... Alors franchement, les quelques 135000
octets avant d'avoir une erreur me laissent perplexe :/
L'appel système d'allocation de mémoire se nomme brk(2). malloc(3) est
un sous-programme qui tourne en mode utilisateur pour rendre plus
conviviale l'allocation mémoire. Il demande en général bien plus de
mémoire que ce qu'a réclamé le programmeur, pour la distribuer ensuite
à loisir (alors que brk, de plus bas niveau, alloue exactement ce qui
est demandé).
Le comportement que vous observez est donc parfaitement normal.
Cf. les sources de la GNU libc, répertoire "malloc/" ou bien
http://www.malloc.de/en/index.html.
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
On Mon, Dec 13, 2004 at 01:14:35AM +0100, Baptiste Mathus wrote a message of 94 lines which said:
ça affiche bien 4096... Alors franchement, les quelques 135000 octets avant d'avoir une erreur me laissent perplexe :/
L'appel système d'allocation de mémoire se nomme brk(2). malloc(3) est un sous-programme qui tourne en mode utilisateur pour rendre plus conviviale l'allocation mémoire. Il demande en général bien plus de mémoire que ce qu'a réclamé le programmeur, pour la distribuer ensuite à loisir (alors que brk, de plus bas niveau, alloue exactement ce qui est demandé).
Le comportement que vous observez est donc parfaitement normal.
Cf. les sources de la GNU libc, répertoire "malloc/" ou bien http://www.malloc.de/en/index.html.
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Thomas Pimmel
Salut,
Le dimanche 12 Décembre 2004 22:54, Baptiste Mathus a écrit :
Or le nombre est bcp plus gd que ça : 137400. Soit j'ai fait une connerie ds les 15 lignes que j'ai écrites (honte sur moi) soit je comprends plus...
Non, pas d'erreurs à priori. Mais il me semblerait logique que les segments non-réservés ne fassent pas l'objet d'un traitement de la mmu. Tant que ton programme ne tape pas dans de la mémoire allouée par un autre prog, pas de raison d'avoir une interruption... non ? (Je dis ça, mais bon...)
Autre test à effectuer : prévois une boucle de delai de trente secondes entre l'allocation et le remplissage. Pendant ce temps, lance d'autres applications gourmandes (genre gimp) et regarde ce que ça fait.
A+, Tom -- Thomas Pimmel email : http : http://tom.ringard.org
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
Salut,
Le dimanche 12 Décembre 2004 22:54, Baptiste Mathus a écrit :
Or le nombre est bcp plus gd que ça : 137400. Soit j'ai fait une connerie
ds les 15 lignes que j'ai écrites (honte sur moi) soit je comprends plus...
Non, pas d'erreurs à priori. Mais il me semblerait logique que les segments
non-réservés ne fassent pas l'objet d'un traitement de la mmu. Tant que ton
programme ne tape pas dans de la mémoire allouée par un autre prog, pas de
raison d'avoir une interruption... non ? (Je dis ça, mais bon...)
Autre test à effectuer : prévois une boucle de delai de trente secondes entre
l'allocation et le remplissage. Pendant ce temps, lance d'autres applications
gourmandes (genre gimp) et regarde ce que ça fait.
A+, Tom
--
Thomas Pimmel
email : tom@ringard.org
http : http://tom.ringard.org
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Le dimanche 12 Décembre 2004 22:54, Baptiste Mathus a écrit :
Or le nombre est bcp plus gd que ça : 137400. Soit j'ai fait une connerie ds les 15 lignes que j'ai écrites (honte sur moi) soit je comprends plus...
Non, pas d'erreurs à priori. Mais il me semblerait logique que les segments non-réservés ne fassent pas l'objet d'un traitement de la mmu. Tant que ton programme ne tape pas dans de la mémoire allouée par un autre prog, pas de raison d'avoir une interruption... non ? (Je dis ça, mais bon...)
Autre test à effectuer : prévois une boucle de delai de trente secondes entre l'allocation et le remplissage. Pendant ce temps, lance d'autres applications gourmandes (genre gimp) et regarde ce que ça fait.
A+, Tom -- Thomas Pimmel email : http : http://tom.ringard.org
-- Pensez à lire la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact