| Taz |
1) oui, changer d'algo. changer d'allocateur oui mais toujours avec les mêmes limites. Si t'es en C++ et que tu mmap un fichier, tu peux planquer ça dans un fichier et mapper une région à la demande. Découpe en plusieurs processus (c'est une technique courante).
2) tu n'as pas regarder pmap. Sur une machine 32bits, quelque soit le nombre de Go que peux adresser le noyau (avec des mécanismes d'indirections), côté utilisateur -- dans ton programme -- l'adressage mémoire est plat. Ça correspond à toute valeur stockage dans un pointeur. Donc tu comprends bien que sur 32 bits, t'es limités à 32bits. En fait moins que ça : linux partage l'espace d'adressage utilisateur en 2. Classiquement 1G noyau / 3G utilisateur. Par noyau, c'est à dire mémoire utilisé par le noyau pour un processus donné. Déjà tu n'as plus que 3G d'espace d'adressage. Ensuite, les différents segments d'un processus commencent à des offsets distincts (souvent quasi fixes(ici des exemples bidons)) : par exemple la pile va démarré à partir de la fin (on va dire 0xf......), les tas (lui d'une capacité max de 896M) à partir de 0x3......, le texte à partir de 0x08......, les mappings mémoire à partir de 0xc......., etc
Donc quand tu démarres ton processus, dès le départ, il y a de fragmentation inhérente. Elle est structurelle et voulue, puisque l'adressage dans un processus est directe. Ta pile a besoin d'espace réservé pour grandir (même si non alloué), idem pour le tas, etc.
Je suis sur que si tu fais des tests, avec un programme bidon, tu n'arriveras pas à mapper plus de 1,5G. Parce que sur l'espace d'adressage, aucune plage disponible ne fait cette taille. Donc avec un processus déjà gourmand en mémoire, c'est encore plus dur. D'où de fréquents échecs.
Là je travail sur mon ppc. Un truc m'intrigue c'est l'adresse de base de la pile qui restreint un peu plus l'espace d'adressage. Avec le programme suivant
Code :
- #include <stdlib.h>
- #include <stdio.h>
- #include <string.h>
- #include <errno.h>
- void * my_xmalloc(size_t n)
- {
- char *p = malloc(n);
- if (!p) {
- fprintf(stderr, "Failed to allocated %lu bytes : %s\n",
- (unsigned long)n, strerror(errno));
- exit(42);
- }
- p[0] = p[n/2] = p[n-1] = 'X';
- return p;
- }
- int main(int argc, char **argv)
- {
- unsigned long n, size;
- unsigned long long total;
- unsigned i;
- void **p;
- if (argc != 3)
- return 1;
- n = strtoul(argv[1], NULL, 0);
- size = strtoul(argv[2], NULL, 0);
- total = ((unsigned long long)n) * size;
- printf("%lu * %lu = %llu (%lluM)\n", n, size, total, total >> 20);
- p = my_xmalloc(n * sizeof *p);
- for (i = 0; i < n; ++i)
- p[i] = my_xmalloc(size);
- puts("alloc OK" );
- getchar();
- for (i = 0; i < n; ++i)
- free(p[i]);
- free(p);
- return 0;
- }
|
j'arrive au maximum a occuper
[16:28:06][pts/4][/tmp][#58]
benoit@ibook >>> ./a.out 18 100000000
18 * 100000000 = 1800000000 (1716M)
alloc OK
[16:28:33][pts/4][/tmp][#59]
benoit@ibook >>> ./a.out 19 100000000
19 * 100000000 = 1900000000 (1811M)
Failed to allocated 100000000 bytes : Cannot allocate memory
|
et ce, en utilisant des morceaux de 100M.
Par contre, le plus gros mappage mémoire possible est plus petit
[16:29:31][pts/4][/tmp][#66] ? 130
benoit@ibook >>> ./a.out 1 1300000000
1 * 1300000000 = 1300000000 (1239M)
alloc OK
[16:29:34][pts/4][/tmp][#67] ? 130
benoit@ibook >>> ./a.out 1 1400000000
1 * 1400000000 = 1400000000 (1335M)
Failed to allocated 1400000000 bytes : Cannot allocate memory |
Bref : rien à avoir avec la mémoire du système, qui peut atteindre plusieurs G sur un système 32bits (avec des histoires de HIMEM, indirection au niveau du noyau, VM, etc). Le problème c'est que tes processus ont un adressage plat de 32bits, "fragmenté" exprès.
Anecdote : un système 64bits ça arrange tout. Sauf si t'as un OS pourri genre OSX, qui a un noyau 64bits, mais garde des process avec espace d'adressage 32bits. Résultat, apple t'explique que pour tirer partie de tout ça, il faut apprendre des techniques haut-niveau de répartition en processus. Minable |
