Warum frisst dieser Speicherfresser nicht wirklich Speicher?

Ich möchte ein Programm erstellen, das eine OOM-Situation (Out-of-Memory) auf einem Unix-Server simuliert. Ich habe diesen supereinfachen Speicherfresser erstellt:

#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;
}

Es verbraucht so viel Speicher wie definiert, in memory_to_eatdem jetzt genau 50 GB RAM vorhanden sind. Es ordnet Speicher um 1 MB zu und druckt genau den Punkt, an dem es nicht mehr zuordnen kann, so dass ich weiß, welchen Maximalwert es geschafft hat, zu essen.

Das Problem ist, dass es funktioniert. Auch auf einem System mit 1 GB physischem Speicher.

Wenn ich oben nachschaue, sehe ich, dass der Prozess 50 GB virtuellen Speicher und nur weniger als 1 MB residenten Speicher verbraucht. Gibt es eine Möglichkeit, einen Speicherfresser zu erstellen, der ihn wirklich verbraucht?

Systemspezifikationen: Linux-Kernel 3.16 ( Debian ) höchstwahrscheinlich mit aktiviertem Overcommit (nicht sicher, wie man es auscheckt) ohne Swap und virtualisiert.

Wenn Ihre malloc()Implementierung Speicher vom Systemkern anfordert (über einen sbrk()oder einen mmap()Systemaufruf), notiert der Kernel nur, dass Sie den Speicher angefordert haben und wo er in Ihrem Adressraum abgelegt werden soll. Diese Seiten werden noch nicht zugeordnet .

Wenn der Prozess anschließend auf den Speicher innerhalb der neuen Region zugreift, erkennt die Hardware einen Segmentierungsfehler und warnt den Kernel vor dem Zustand. Der Kernel sucht dann die Seite in seinen eigenen Datenstrukturen und stellt fest, dass Sie dort eine Nullseite haben sollten, sodass er einer Nullseite zugeordnet wird (möglicherweise wird zuerst eine Seite aus dem Seiten-Cache entfernt) und vom Interrupt zurückkehrt. Ihr Prozess erkennt nicht, dass dies geschehen ist. Die Kerneloperation ist vollkommen transparent (mit Ausnahme der kurzen Verzögerung, während der Kernel seine Arbeit erledigt).

Durch diese Optimierung kann der Systemaufruf sehr schnell zurückgegeben werden, und vor allem werden Ressourcen vermieden, die bei der Zuordnung für Ihren Prozess festgeschrieben werden. Dies ermöglicht es Prozessen, ziemlich große Puffer zu reservieren, die sie unter normalen Umständen niemals benötigen, ohne befürchten zu müssen, zu viel Speicher zu verschlingen.

Wenn Sie also einen Speicherfresser programmieren möchten, müssen Sie unbedingt etwas mit dem von Ihnen zugewiesenen Speicher tun. Dazu müssen Sie Ihrem Code nur eine einzige Zeile hinzufügen:

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;
    }
}

Beachten Sie, dass es vollkommen ausreichend ist, auf jeder Seite in ein einzelnes Byte zu schreiben (das auf X86 4096 Bytes enthält). Dies liegt daran, dass die gesamte Speicherzuweisung vom Kernel zu einem Prozess bei der Speicherseitengranularität erfolgt, was wiederum auf die Hardware zurückzuführen ist, die kein Paging bei kleineren Granularitäten zulässt.

Alle virtuellen Seiten beginnen mit dem Kopieren beim Schreiben, das derselben physischen Seite mit Null zugeordnet ist. Um physische Seiten zu verbrauchen, können Sie sie verschmutzen, indem Sie auf jede virtuelle Seite etwas schreiben.

Wenn Sie als Root ausgeführt werden, können Sie die Seiten verwenden mlock(2)oder mlockall(2)den Kernel verkabeln lassen, wenn sie zugewiesen sind, ohne sie verschmutzen zu müssen. (Normale Nicht-Root-Benutzer haben ulimit -lnur 64 KB.)

Wie viele andere vorgeschlagen haben, scheint der Linux-Kernel den Speicher nur dann wirklich zuzuweisen, wenn Sie darauf schreiben

Eine verbesserte Version des Codes, die genau das tut, was das OP wollte:

Dadurch werden auch die Nichtübereinstimmungen der Zeichenfolgen im printf-Format mit den Typen memory_to_eat und ate_memory behoben, mit denen Ganzzahlen %zigedruckt werden size_t. Die zu essende Speichergröße in kiB kann optional als Befehlszeilenargument angegeben werden.

Das chaotische Design, das globale Variablen verwendet und um 1 KB anstelle von 4 KB Seiten wächst, bleibt unverändert.

#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;
}

Hier wird eine sinnvolle Optimierung vorgenommen. Die Laufzeit erfasst den Speicher erst, wenn Sie ihn verwenden.

Eine einfache memcpywird ausreichen, um diese Optimierung zu umgehen. (Möglicherweise callocwird dadurch die Speicherzuordnung bis zum Verwendungsort noch optimiert.)

Ich bin mir nicht sicher, aber die einzige Erklärung, die ich finden kann, ist, dass Linux ein Copy-on-Write-Betriebssystem ist. Wenn man aufruft, zeigen forkbeide Prozesse auf denselben physischen Speicher. Der Speicher wird nur kopiert, wenn ein Prozess tatsächlich in den Speicher schreibt.

Ich denke hier wird der tatsächliche physische Speicher nur zugewiesen, wenn man versucht, etwas darauf zu schreiben. Aufruf sbrkoder mmapmöglicherweise nur Aktualisierung der Speicherbuchhaltung des Kernels. Der tatsächliche RAM kann nur zugewiesen werden, wenn wir tatsächlich versuchen, auf den Speicher zuzugreifen.