Pourquoi ce mangeur de mémoire ne mange-t-il pas vraiment de mémoire?

Je veux créer un programme qui simulera une situation de manque de mémoire (MOO) sur un serveur Unix. J'ai créé ce mangeur de mémoire super simple:

#include <stdio.h>
#include <stdlib.h>

unsigned long long memory_to_eat = 1024 * 50000;
size_t eaten_memory = 0;
void *memory = NULL;

int eat_kilobyte()
{
    memory = realloc(memory, (eaten_memory * 1024) + 1024);
    if (memory == NULL)
    {
        // realloc failed here - we probably can't allocate more memory for whatever reason
        return 1;
    }
    else
    {
        eaten_memory++;
        return 0;
    }
}

int main(int argc, char **argv)
{
    printf("I will try to eat %i kb of ram\n", memory_to_eat);
    int megabyte = 0;
    while (memory_to_eat > 0)
    {
        memory_to_eat--;
        if (eat_kilobyte())
        {
            printf("Failed to allocate more memory! Stucked at %i kb :(\n", eaten_memory);
            return 200;
        }
        if (megabyte++ >= 1024)
        {
            printf("Eaten 1 MB of ram\n");
            megabyte = 0;
        }
    }
    printf("Successfully eaten requested memory!\n");
    free(memory);
    return 0;
}

Il consomme autant de mémoire que défini dans memory_to_eatlequel se trouve maintenant exactement 50 Go de RAM. Il alloue de la mémoire de 1 Mo et imprime exactement le point où il ne parvient pas à en allouer davantage, de sorte que je sache quelle valeur maximale il a réussi à manger.

Le problème est que cela fonctionne. Même sur un système avec 1 Go de mémoire physique.

Lorsque je vérifie haut, je vois que le processus consomme 50 Go de mémoire virtuelle et seulement moins de 1 Mo de mémoire résidente. Existe-t-il un moyen de créer un mangeur de mémoire qui le consomme vraiment?

Spécifications du système: noyau Linux 3.16 ( Debian ) très probablement avec overcommit activé (je ne sais pas comment le vérifier) ​​sans swap et virtualisé.

Lorsque votre malloc()implémentation demande de la mémoire au noyau système (via un appel sbrk()ou un mmap()appel système), le noyau note uniquement que vous avez demandé la mémoire et où elle doit être placée dans votre espace d'adressage. Il ne mappe pas encore ces pages .

Lorsque le processus accède ultérieurement à la mémoire dans la nouvelle région, le matériel reconnaît une erreur de segmentation et alerte le noyau de la condition. Le noyau recherche alors la page dans ses propres structures de données, et trouve que vous devriez y avoir une page zéro, donc il mappe dans une page zéro (peut-être d'abord expulser une page du cache de page) et revient de l'interruption. Votre processus ne se rend pas compte que rien de tout cela s'est produit, le fonctionnement du noyau est parfaitement transparent (à l'exception du court délai pendant lequel le noyau fait son travail).

Cette optimisation permet à l'appel système de revenir très rapidement et, surtout, elle évite que des ressources soient engagées dans votre processus lorsque le mappage est effectué. Cela permet aux processus de réserver des tampons assez volumineux dont ils n'ont jamais besoin dans des circonstances normales, sans craindre d'absorber trop de mémoire.

Donc, si vous voulez programmer un mangeur de mémoire, vous devez absolument faire quelque chose avec la mémoire que vous allouez. Pour cela, il vous suffit d'ajouter une seule ligne à votre code:

int eat_kilobyte()
{
    if (memory == NULL)
        memory = malloc(1024);
    else
        memory = realloc(memory, (eaten_memory * 1024) + 1024);
    if (memory == NULL)
    {
        return 1;
    }
    else
    {
        //Force the kernel to map the containing memory page.
        ((char*)memory)[1024*eaten_memory] = 42;

        eaten_memory++;
        return 0;
    }
}

Notez qu'il est parfaitement suffisant d'écrire sur un seul octet dans chaque page (qui contient 4096 octets sur X86). En effet, toutes les allocations de mémoire du noyau à un processus sont effectuées avec une granularité de page mémoire, ce qui est, à son tour, à cause du matériel qui ne permet pas la pagination à des granularités plus petites.

Toutes les pages virtuelles commencent par copie sur écriture mappées sur la même page physique remise à zéro. Pour utiliser des pages physiques, vous pouvez les salir en écrivant quelque chose sur chaque page virtuelle.

Si vous exécutez en tant que root, vous pouvez utiliser mlock(2)ou mlockall(2)demander au noyau de câbler les pages lorsqu'elles sont allouées, sans avoir à les salir. (les utilisateurs normaux non root ont ulimit -lseulement 64 ko.)

Comme beaucoup d'autres l'ont suggéré, il semble que le noyau Linux n'alloue pas vraiment la mémoire à moins que vous n'écriviez dessus

Une version améliorée du code, qui fait ce que l'OP voulait:

Cela corrige également les incompatibilités de chaîne de format printf avec les types de memory_to_eat et eaten_memory, en utilisant %zipour imprimer des size_tentiers. La taille de la mémoire à manger, en kio, peut éventuellement être spécifiée sous forme d'argument de ligne de commande.

La conception désordonnée utilisant des variables globales et augmentant de 1k au lieu de 4k pages, reste inchangée.

#include <stdio.h>
#include <stdlib.h>

size_t memory_to_eat = 1024 * 50000;
size_t eaten_memory = 0;
char *memory = NULL;

void write_kilobyte(char *pointer, size_t offset)
{
    int size = 0;
    while (size < 1024)
    {   // writing one byte per page is enough, this is overkill
        pointer[offset + (size_t) size++] = 1;
    }
}

int eat_kilobyte()
{
    if (memory == NULL)
    {
        memory = malloc(1024);
    } else
    {
        memory = realloc(memory, (eaten_memory * 1024) + 1024);
    }
    if (memory == NULL)
    {
        return 1;
    }
    else
    {
        write_kilobyte(memory, eaten_memory * 1024);
        eaten_memory++;
        return 0;
    }
}

int main(int argc, char **argv)
{
    if (argc >= 2)
        memory_to_eat = atoll(argv[1]);

    printf("I will try to eat %zi kb of ram\n", memory_to_eat);
    int megabyte = 0;
    int megabytes = 0;
    while (memory_to_eat-- > 0)
    {
        if (eat_kilobyte())
        {
            printf("Failed to allocate more memory at %zi kb :(\n", eaten_memory);
            return 200;
        }
        if (megabyte++ >= 1024)
        {
            megabytes++;
            printf("Eaten %i  MB of ram\n", megabytes);
            megabyte = 0;
        }
    }
    printf("Successfully eaten requested memory!\n");
    free(memory);
    return 0;
}

Une optimisation sensible est en cours ici. Le moteur d' exécution ne fait pas acquérir la mémoire jusqu'à ce que vous l' utilisez.

Un simple memcpysuffira pour contourner cette optimisation. (Vous constaterez peut-être que cela callocoptimise encore l'allocation de mémoire jusqu'au point d'utilisation.)

Je ne suis pas sûr de celui-ci, mais la seule explication dont je peux parler est que linux est un système d'exploitation de copie sur écriture. Quand on appelle forkles deux processus pointent vers la même mémoire physique. La mémoire n'est copiée qu'une fois qu'un seul processus est réellement ÉCRIT dans la mémoire.

Je pense qu'ici, la mémoire physique réelle n'est allouée que lorsque l'on essaie d'y écrire quelque chose. L'appel sbrkou mmappeut bien ne mettre à jour que la comptabilité de la mémoire du noyau. La RAM réelle ne peut être allouée que lorsque nous essayons réellement d'accéder à la mémoire.