[memory] Statistiques occupation mémoire

[MaximeCheramy]

Message original de Nico sur redmine:

Je soupçonne la présence d'un nombre incroyable de fuites de mémoire dans le noyau. De là m'est venu une idée de fonctionnalité: Garder des données sur la mémoire utilisée par un processus. L'idée est de connaitre la mémoire occupée en "statique" (ie la mémoire occupée de base par un processus quand il est chargé en mémoire) ainsi que la mémoire occupée dynamiquement, c'est à dire allouée avec des mallocs. Connaitre la mémoire allouée statiquement ne doit pas être trop compliqué je pense. Pour la mémoire allouée dynamiquement, la piste qui me semble convenir le mieux serait de stocker les données dans la structure virtual_mem (vmm.h) et de les mettre à jour à chaque malloc/free. Cette solution est intéressant dans le fait qu'elle fonctionnera que ce soit pour le kernel ou les processus (kmalloc et malloc utilisent tout deux des structures virtual_mem)

---

Et je suis d'accord sur l'intéret de tracer les fuites. Je sais qu'il y a des fuites dans mon code mais ce n'est pas évident à détecter sans outils.

Pour info je suis tombé sur le projet kmemleak qui visait à ajouter le traçage de la mémoire pour linux et peut être que cela pourrait nous inspirer :

+Basic Algorithm +--------------- + +The memory allocations via kmalloc, vmalloc, kmem_cache_alloc and +friends are tracked and the pointers, together with additional +information like size and stack trace, are stored in a hash table. The +corresponding freeing function calls are tracked and the pointers +removed from the hash table. + +An allocated block of memory is considered orphan if no pointer to its +start address or to an alias (pointer aliases are explained later) can +be found by scanning the memory (including saved registers). This +means that there might be no way for the kernel to pass the address of +the allocated block to a freeing function and therefore the block is +considered a leak. + +The scanning algorithm steps: +

• 1. mark all objects as white (remaining white objects will later be
• considered orphan)
• 2. scan the memory starting with the data section and stacks,
• checking the values against the addresses stored in the hash
• table. If a pointer to a white object is found, the object is
• added to the grey list
• 3. scan the grey objects for matching addresses (some white objects
• can become grey and added at the end of the grey list) until the
• grey set is finished
• 4. the remaining white objects are considered orphan and reported
• via /sys/kernel/debug/memleak

[MaximeCheramy]

Ce qui serait bien, ce serait d'avoir accès à la mémoire disponible depuis l'userspace pour pouvoir constater des augmentations d'utilisation mémoire suite à certains syscall.

[MaximeCheramy]

Je fais le point rapidement sur ce ticket :

• Nous avons une commande free qui nous permet de constater qu'il y a bien des fuites mémoires
• Toutes les allocations de page sont mémorisées pour chaque process afin de systématiquement les libérer lors du sys_exit.

Mais ce n'est pas suffisant pour identifier clairement les fuites mémoire.