Le seul outil qui te donnera les info fiable sur le sujet, c'est massif l'outil de valgrind. Sinon tu peux creer une lib qui intercepte tous les appel aux fonctions d'allocation (malloc,mmap,brk,...) et faire tes mesures toi meme.

Mais syncerement, massif pour analyser la conso memoire et callgrind pour analyser le temp passe dans chaque operation sont les deux seuls outils qui te donneront des informations fiables et utilisable.

Tu peux toujours reimplementer un malloc bete qui appelle le vrai (via un syscall sinon ça va boucler severe avant de peter la pile ...) mais qui en profite pour comptabiliser dans une globale statique la taille memoire allouée et pourquoi pas generer un graphique via un thread. le tout dans une lib dynamique prechargée via un LD_PRELOAD.
ca ralentira considerablement le processus, mais tu pourra l'appliquer a n'importe quel process.

Et en utilisant la struct rusage que te fournit wait4, et notamment les membres :

long ru_maxrss; /* max resident set size */
#define ru_first ru_ixrss
long ru_ixrss; /* integral shared memory size */
long ru_idrss; /* integral unshared data " */
long ru_isrss; /* integral unshared stack " */

tu n'as pas cette info ?

Source :
man 2 wait4
/usr/include/sys/ressource.h

http://labs.o-hand.com/exmap-console/

Exemple pour le processus nautilus :

exmap nautilus
http://pastebin.com/m73c72c92

Exmap est très verbeux par défault, mais il y a des options de filtrage et de tri. Il t'affiche aussi une donnée bien sympathique: le "sole use" qui est la quantité de mémoire réellement consommée par le processus. Par exemple pour une appli GTK, les bibliothèques GTK sont partagées entre différent processus. Le sole use ne montre donc que la mémoire que seule cette application utilise, ce qui est un bonne indicateur de sa consommation mémoire réelle, quand tu es dans l'environnement cible. Ici, nautilus consommerait plus en "sole use" s'il était chargé dans un environnement KDE, vu qu'il serait la seule appli en cours d'utilisation utilisant les bibliothèques GNOME.

Voici une vue plus synthétique des informations fournies par exmap :
exmap --no-file-info nautilus
Process 4397 [nautilus]
Virtual memory : 92812 KB
Effective VM : 86660 KB
Heap : 6680 KB
Stack : 260 KB
vdso : 0 B
Mapped : 18704 KB
Effective mapped: 12552 KB
Sole use : 8792 KB

Et ce petit truc, ça peut pas aider ?


/*
* Warning: this function was a GNU/Linuxism !
*/
malloc_stats();


J'ai testé toutes les méthodes proposées :
- valgrind avec massif
- valgrind avec memcheck
- exmap
- le grep de VmPeak

Pas un seul ne donne les mêmes résultats. En effet, entre les effets de partages mémoire (library), le COW, l'allocation paraisseuse (après un malloc il faut effectivement accéder à une page pour qu'elle soit lu), que le chiffre est différent.

memcheck donne ce qui est demander par malloc(). Dans mon cas, 3Go.
massif donne des résultats étranges sur mon cas de test. Mais je n'ai pas la dernière version.
exmap marque les pages utilisées réellement par le noyau (c'est un module noyau), on a donc les pages utilisées uniquement par le processus analysées (125Ko dans mon cas).

Vmpeak correspond à la demande au système de pagination du noyau. J'ai 1Go dans mon cas, ce qui correspond à ma RAM (qui est inférieur au malloc de 3Go).

Mon cas de test est spécial, mais finalement, cela montre bien la complexité de mesure de la mémoire consommée.