Re: Taille processus limitee ?

["Edouard G. Parmelan" <edouard.parmelan@quadratec.fr>]

Nicolas Kowalski wrote:

> J'ai finalement trouvé une solution à ce problème. Elle concerne la
> taille et nombre des blocs alloués. J'ai utilisé le programme
> précédent pour faire quelques statitistiques :
> 
> - `chunk' est la taille demandée pour chaque malloc
> - `total' est le nombre total d'octets alloués
> - le dernier nombre indique le nombre de malloc ayant réussi.
> 
> failure, chunk = 1024, total=576799744
> Number of malloc: 563282
...
> failure, chunk = 1048576, total=1654652928
> Number of malloc: 1579
> 
> ...
> A partir de là les machines s'écroulent, j'ai alors laissé tomber.
> 
> 
> Bref, pour ne pas être ennuyés, les développeurs du labo vont devoir
> repondre eux-mêmes la gestion de la mémoire :-|.
> Je subodore un bug de la glibc...

Il faut savoir que la glibc utilise 2 méthodes différents pour répondre
à un malloc() et ceux suivant la taille demandée.  Je ne sais plus de
mémoire quel est la barrière mais ce n'est pas important.

Pour les petites allocations, c'est réaliser sur le tas avec du sbrk()
ou équivalent.

Pour les grosses allocations, c'est du mmap() anonyme de /dev/zero.

Voici le résulta du source attaché

stack  0xbffff918
main   0x8048580
sbrk   0x80498f8
malloc 0x8049900
malloc 0x806d8b8
sbrk   0x806e000
mmap   0x400f6000
malloc 0x40116008
sysmem cat /proc/25007/maps
08048000-08049000 r-xp 00000000 00:09 64569      /misc/people3/egp/tmp/x
08049000-0804a000 rw-p 00000000 00:09 64569      /misc/people3/egp/tmp/x
0804a000-0806e000 rwxp 00000000 00:00 0
40000000-40012000 r-xp 00000000 08:06 6184       /lib/ld-2.1.3.so
40012000-40014000 rw-p 00011000 08:06 6184       /lib/ld-2.1.3.so
40014000-40015000 rw-p 00000000 00:00 0
40019000-400ee000 r-xp 00000000 08:06 6195       /lib/libc-2.1.3.so
400ee000-400f2000 rw-p 000d4000 08:06 6195       /lib/libc-2.1.3.so
400f2000-400f6000 rw-p 00000000 00:00 0
400f6000-40116000 rw-p 00000000 08:06 72599      /dev/zero
40116000-40137000 rw-p 00000000 00:00 0
bfffe000-c0000000 rwxp fffff000 00:00 0


Les petits malloc() seront réalisés entre le premier sbrk (qui commence
à 0x08049000) et le premier mmap (aka 0x40000000).  Sans oublier les
entêtes de gestion de chaque zone mappé.

Les gros malloc() entre le dernier mmap et la stack.

L'espace virtuel diponnible est alors en gros 0x08049000 - 0x40000000
pour les petits mallocs (à noter le début du tas dépends du programme)
et 0x400f6000 - 0xbfffe000 pour les gros malloc() en sachant que la
stack peux grossir vers le bas (sur Intel) et doc prendre sur la zone
mmap.

Voila, ulimit -m unlimited m'est me veux pas dire utilise toute la
mémoire.
-- 
Edouard G. Parmelan
http://egp.free.fr

#include <stdio.h>
#include <stdlib.h>
#include <fcntl.h>
#include <unistd.h>
#include <sys/mman.h>

int main()
{
    int i;
    char *p;
    int fd;
    char cmd[128];

    printf ("stack  %p\n", cmd);
    printf ("main   %p\n", &main);
    printf ("sbrk   %p\n", sbrk(0));

    p = malloc (64);
    printf ("malloc %p\n", p);
    for (i = 64; i < 128 * 1024; i += 64)
	p = malloc (64);
    printf ("malloc %p\n", p);
    printf ("sbrk   %p\n", sbrk(0));

    fd = open ("/dev/zero", O_RDWR);
    p = mmap (NULL, 128 * 1024, PROT_READ|PROT_WRITE, MAP_PRIVATE, fd, 0); 
    close (fd);

    printf ("mmap   %p\n", p);

    p = malloc (128 * 1024);
    printf ("malloc %p\n", p);

    sprintf (cmd, "cat /proc/%d/maps", getpid());
    printf ("sysmem %s\n", cmd);
    system (cmd);
}