Por qué el sistema operativo administra la memoria

1. La memoria, un recurso que todos necesitan

Un procesador solo sabe hacer dos cosas con los datos: operar con los que tiene en sus registros y traer o llevar datos de la memoria principal, la RAM. Un programa guardado en el disco no puede ejecutarse: para que la CPU lea una instrucción o un dato, éste tiene que estar antes en la memoria. Por eso, cada proceso que existe en el sistema ocupa memoria: su código, sus variables globales, su pila, los bloques que pidió con malloc.

La RAM es, además, un recurso finito y compartido. Un equipo de escritorio puede tener 16 GiB; en él conviven el navegador, el editor, el sistema de ventanas, decenas de servicios y el propio núcleo. Ninguno de esos programas sabe de los demás, y todos están escritos como si la memoria fuera solo suya. El sistema operativo es quien hace posible esa convivencia, y la parte del núcleo que se ocupa de ello se llama gestor de memoria.

Gestión de memoria es el conjunto de mecanismos con que el sistema operativo, ayudado por el hardware, decide qué parte de la memoria usa cada proceso, controla qué accesos se permiten y mueve datos entre la RAM y el disco cuando hace falta.

2. Sin sistema operativo: un programa, toda la memoria

Para apreciar lo que hace el gestor de memoria conviene imaginar su ausencia. En los primeros computadores, y todavía hoy en muchos microcontroladores, solo corre un programa a la vez y ocupa toda la memoria. Las direcciones que usa el programa son directamente posiciones de la RAM: la variable x está en la posición 0x2000 y siempre en la 0x2000. Es un modelo muy simple, pero tiene dos defectos graves:

• Desaprovecha la CPU. Cuando el programa espera al disco o al teclado, el procesador no hace nada, y esas esperas son larguísimas comparadas con su velocidad.
• No hay defensa. Un error en el programa puede escribir sobre cualquier posición, incluida la de las rutinas que lo cargaron o la de los dispositivos.

La solución es tener varios programas cargados a la vez y pasar la CPU de uno a otro cuando alguno espera. Eso se llama multiprogramación y es el origen de todos los problemas que estudia este curso.

3. Varios programas a la vez: tres problemas

En cuanto dos programas comparten la RAM, aparecen tres dificultades que no existían antes:

Hay una cuarta cuestión, de eficiencia: aun cuando todo cabe y está protegido, el reparto tiene que ser barato. Traducir direcciones en cada acceso, o llevar al disco una página, cuesta tiempo, y si el sistema lo hiciera sin cuidado todos los programas irían lentos. Una buena parte del curso trata precisamente de hacer estas tareas casi gratis (la TLB, el reemplazo de páginas, el copy-on-write).

Veamos ahora que Linux resuelve de verdad estos tres problemas, con tres programas cortos. Todos se compilan con gcc -std=c17 -Wall -Wextra y los resultados que se muestran vienen de una ejecución real.

4. Experimento: la misma dirección, dos valores

El primer programa declara una variable global, crea un proceso hijo con fork y hace que el hijo la modifique. Después cada uno imprime la dirección de la variable y su valor. El padre espera a que el hijo termine, para que las líneas salgan siempre en el mismo orden:

#define _POSIX_C_SOURCE 200809L
#include <stdio.h>
#include <stdlib.h>
#include <sys/wait.h>
#include <unistd.h>

int valor = 42;                          /* variable global: una sola, en la dirección que sea */

int main(void)
{
    pid_t pid = fork();
    if (pid == -1) {
        perror("fork");
        return 1;
    }
    if (pid == 0) {
        valor = 99;                      /* el hijo la modifica */
        printf("hijo   (pid %d): &valor = %p, valor = %d\n", getpid(), (void *)&valor, valor);
        return 0;
    }
    if (waitpid(pid, NULL, 0) == -1) {
        perror("waitpid");
        return 1;
    }
    printf("padre  (pid %d): &valor = %p, valor = %d\n", getpid(), (void *)&valor, valor);
    return 0;
}

$ gcc -std=c17 -Wall -Wextra -o aislamiento aislamiento.c
$ ./aislamiento
hijo   (pid 547): &valor = 0x559edd2f6010, valor = 99
padre  (pid 546): &valor = 0x559edd2f6010, valor = 42
$ ./aislamiento
hijo   (pid 549): &valor = 0x56c0f37d8010, valor = 99
padre  (pid 548): &valor = 0x56c0f37d8010, valor = 42

Hay que leer este resultado con calma, porque contiene la idea central del curso:

• La dirección es la misma en los dos procesos (0x559edd2f6010) y, sin embargo, el valor es distinto: 99 en el hijo, 42 en el padre. Una misma «dirección» no puede ser una posición física única de la RAM; tiene que ser algo que cada proceso interpreta a su manera. Es una dirección virtual, y el sistema la traduce a una posición física diferente para cada proceso. Lo verás con detalle en el tema 3.
• Lo que hace el hijo no afecta al padre. Cada proceso tiene su propio espacio de direcciones: eso es el aislamiento. (Por dentro, fork no copia la memoria al crear el hijo; la copia solo cuando alguno escribe. Es el tema 31.)
• La dirección cambia entre una ejecución y otra (0x559e… y 0x56c0…) porque Linux la aleatoriza al cargar el programa, una defensa contra ataques llamada ASLR que veremos en el tema 5.

5. Experimento: una dirección que no es tuya

El aislamiento se completa con la protección: no basta con que cada proceso tenga su espacio, hay que impedir que acceda a lo que no es suyo. El segundo programa intenta leer un byte de una dirección que recibe como argumento:

#define _POSIX_C_SOURCE 200809L
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
    unsigned long direccion = argc > 1 ? strtoul(argv[1], NULL, 0) : 0x1000;
    volatile char *p = (volatile char *)direccion;

    printf("voy a leer la dirección %p\n", (const void *)p);
    fflush(stdout);
    char c = *p;                         /* ¿pertenece esa dirección a este proceso? */
    printf("leí el byte %d\n", c);
    return 0;
}

$ gcc -std=c17 -Wall -Wextra -o proteccion proteccion.c
$ ./proteccion
voy a leer la dirección 0x1000
Segmentation fault
$ echo $?
139
$ ./proteccion 0x7ffd00000000
voy a leer la dirección 0x7ffd00000000
Segmentation fault

En ambas direcciones el sistema detuvo el programa antes de que leyera nada. El mecanismo es siempre el mismo: la CPU intenta el acceso, el hardware comprueba que esa dirección no corresponde a una zona que el proceso tenga asignada, y lanza una excepción. El núcleo la recibe y le envía al proceso la señal SIGSEGV, cuyo efecto por omisión es terminarlo. El código de salida 139 es 128 + 11, donde 11 es el número de SIGSEGV. La famosa «falla de segmentación» no es un error del compilador ni del lenguaje, sino la protección de memoria funcionando. En C el programador decide a qué dirección apunta un puntero; es el sistema operativo quien decide si puede usarla.

6. Experimento: más memoria de la que hay

El tercer problema es la capacidad. El programa siguiente pide con malloc un bloque de tantos MiB como se le indique y, en tres momentos, lee de /proc/self/status dos cifras: VmSize, la memoria virtual que el proceso tiene reservada, y VmRSS, la parte que está realmente en la RAM:

#define _POSIX_C_SOURCE 200809L
#include <stdio.h>
#include <stdlib.h>
#include <string.h>

/* Muestra las líneas de /proc/self/status que empiezan por VmSize o VmRSS. */
static void mostrar(const char *momento)
{
    FILE *f = fopen("/proc/self/status", "r");
    if (f == NULL) {
        perror("fopen");
        exit(1);
    }
    char linea[256];
    printf("%s\n", momento);
    while (fgets(linea, sizeof linea, f) != NULL)
        if (strncmp(linea, "VmSize", 6) == 0 || strncmp(linea, "VmRSS", 5) == 0)
            printf("  %s", linea);
    fclose(f);
}

int main(int argc, char *argv[])
{
    size_t mib = argc > 1 ? (size_t)strtoul(argv[1], NULL, 10) : 8192;
    size_t bytes = mib << 20;

    mostrar("al empezar:");
    char *bloque = malloc(bytes);
    if (bloque == NULL) {
        fprintf(stderr, "malloc de %zu MiB falló\n", mib);
        return 1;
    }
    printf("malloc(%zu MiB) devolvió %p\n", mib, (void *)bloque);
    mostrar("tras el malloc, sin tocar la memoria:");

    memset(bloque, 1, (size_t)100 << 20);      /* escribir en los primeros 100 MiB */
    mostrar("tras escribir en los primeros 100 MiB:");

    free(bloque);
    return 0;
}

La máquina de pruebas tiene 15 GiB de RAM. Pedimos 8 GiB, y después 200.000 MiB (casi 200 GiB):

$ gcc -std=c17 -Wall -Wextra -o virtual virtual.c
$ ./virtual
al empezar:
  VmSize:	    2764 kB
  VmRSS:	    1408 kB
malloc(8192 MiB) devolvió 0x7d86a1dff010
tras el malloc, sin tocar la memoria:
  VmSize:	 8391376 kB
  VmRSS:	    1536 kB
tras escribir en los primeros 100 MiB:
  VmSize:	 8391376 kB
  VmRSS:	  103936 kB
$ ./virtual 200000
al empezar:
  VmSize:	    2764 kB
  VmRSS:	    1536 kB
malloc de 200000 MiB falló

Tres observaciones:

• Reservar no consume RAM. Tras el malloc de 8 GiB, VmSize saltó de 2,7 MB a unos 8,4 GB, pero VmRSS casi no se movió: el sistema anotó que el proceso podrá usar ese rango de direcciones, y nada más.
• La RAM se entrega al tocar. Al escribir en los primeros 100 MiB, VmRSS subió a unos 104 MB (103.936 kB). El resto del bloque sigue sin existir físicamente. Este mecanismo, la paginación por demanda, es el núcleo del bloque 7.
• Hay un límite, pero no es la RAM instalada. Los 8 GiB cabían en la RAM de esta máquina, pero con la política habitual de Linux el sistema acepta reservas que él estima razonables; casi 200 GiB superan la memoria más el espacio de intercambio disponibles y el malloc devolvió NULL. Por eso en C se comprueba siempre el resultado de malloc.

7. Los tres objetivos del sistema operativo

Los experimentos muestran, uno por uno, qué se espera del gestor de memoria. Resumidos:

Los tres objetivos a veces tiran en direcciones opuestas. Un aislamiento total sería mejor para la seguridad, pero impediría compartir las bibliotecas del sistema, que cargadas una sola vez ahorran cientos de MiB. Una protección muy fina cuesta más tiempo de traducción. Gran parte del diseño de un gestor de memoria consiste en encontrar el equilibrio.

8. Quién hace qué: hardware y sistema operativo

Un detalle importante: el sistema operativo no interviene en cada acceso a memoria. Un programa hace miles de millones por segundo y, si el núcleo tuviera que mirar cada uno, no se podría trabajar. El reparto es este:

• El hardware, una unidad llamada MMU (Memory Management Unit, unidad de gestión de memoria) incluida en el procesador, traduce y comprueba cada dirección al vuelo, usando unas tablas.
• El sistema operativo construye y mantiene esas tablas: decide qué páginas de qué procesos están en la RAM y con qué permisos. Solo se ejecuta cuando algo se sale del caso normal, por ejemplo cuando la MMU avisa de que una página no está presente.

Esta división explica la estructura del curso. Los bloques 3 al 6 describen los mecanismos de traducción (base y límite, segmentación, paginación, TLB), que son sobre todo hardware con una política decidida por el sistema. Los bloques 7 al 9 describen lo que hace el sistema cuando la MMU le pide ayuda.

9. Por qué importa tener varios programas en memoria

Falta dar el motivo cuantitativo de la multiprogramación. Supón que los procesos pasan una fracción p de su tiempo esperando entrada/salida. Con un solo proceso en memoria, la CPU está ociosa esa fracción. Si hay n procesos y sus esperas son independientes, la CPU solo está ociosa cuando los n esperan a la vez, lo que ocurre con probabilidad pⁿ. Es el modelo clásico de la multiprogramación:

Utilización de la CPU = 1 − pⁿ, con p la fracción de tiempo que cada proceso espera E/S y n el número de procesos en memoria (el «grado de multiprogramación»).

Con procesos que esperan el 80 % del tiempo (p = 0,8), que es normal en programas interactivos o que acceden a disco y red:

Cada proceso adicional aprovecha un poco más la CPU, pero cada uno necesita su memoria. El grado de multiprogramación lo limita la RAM: lo que quepa. Esta es la tensión que atraviesa todo el curso. Con más memoria entran más procesos y se usa mejor la CPU. Con técnicas que hagan que cada proceso use menos RAM (cargar solo lo necesario, compartir el código común, llevar al disco lo que no se usa) entran todavía más. Con un reparto mal hecho se pierde espacio en huecos inutilizables, y con demasiados procesos cada uno recibe tan poca memoria que el sistema pasa el tiempo moviendo páginas entre la RAM y el disco: la hiperpaginación del tema 33.

10. Probar con un simulador

Este simulador calcula cuántos procesos caben en la RAM y qué utilización de la CPU resulta. La barra superior dibuja la memoria: el sistema operativo en gris, los procesos en azul y ámbar alternados y, en blanco, la memoria libre. Los valores iniciales (4096 MiB de RAM, 512 para el núcleo, procesos de 700 MiB y esperas del 80 %) dan cinco procesos y un 67 %.

Prueba tres cosas. Sube la espera de E/S al 95 % y comprueba que hacen falta muchos más procesos para llenar la CPU. Pon espera 20 % y observa que más procesos casi no mejoran nada: ya estaba bien aprovechada. Y con los valores iniciales, reduce la memoria por proceso a 350 MiB: la mejora de rendimiento equivale a haber duplicado la RAM, que es lo que hacen en la práctica la paginación por demanda y la compartición de código.

11. Mirar la memoria en Linux

Para terminar, tres herramientas que usarás durante todo el curso. free resume la memoria del equipo, /proc/meminfo da el detalle y /proc/PID/status lo da por proceso:

$ free -h
               total        used        free      shared  buff/cache   available
Mem:            15Gi       595Mi        14Gi       3.5Mi       569Mi        14Gi
Swap:          4.0Gi          0B       4.0Gi
$ getconf PAGESIZE
4096
$ grep -E 'VmSize|VmRSS' /proc/self/status
VmSize:	    4256 kB
VmRSS:	    2304 kB

• total es la RAM instalada; used, la que usan los programas; buff/cache, la que el núcleo emplea como caché de archivos y puede devolver si hace falta. La cifra que importa para saber cuánto queda disponible es available, no free.
• Swap es el espacio de intercambio en disco (tema 40).
• getconf PAGESIZE da el tamaño de página, la unidad en que el sistema reparte la memoria: 4096 bytes. Es el número más importante del curso.
• VmSize y VmRSS son los dos extremos que viste en virtual.c: lo reservado y lo realmente residente.

12. El mapa del curso

Los 52 temas siguen el recorrido de la memoria, desde lo que ve un programa hasta lo que hace el sistema cuando se agota:

Los programas en C se compilan con gcc -std=c17 -Wall -Wextra y se prueban en Linux; los algoritmos se explican además con simuladores como el de este tema. Se da por sabido el C de Programación en C para Sistemas Operativos, en particular los punteros, y lo que cuenta Procesos e Hilos sobre qué es un proceso.

13. Resumen

• Un programa solo se ejecuta si está en la RAM, que es finita y compartida por todos los procesos. El gestor de memoria del sistema operativo la reparte, la protege y la complementa con el disco.
• Al ejecutar varios programas a la vez (multiprogramación) surgen tres problemas: reubicación, protección y capacidad, además de la exigencia de hacerlo con poco costo.
• Los objetivos son tres: abstracción (cada proceso tiene su espacio de direcciones), protección y eficiencia.
• En aislamiento.c padre e hijo tienen la misma dirección con valores distintos (42 y 99): las direcciones de un programa son virtuales.
• En proteccion.c leer una dirección ajena provoca SIGSEGV (código de salida 139): es la protección de memoria funcionando.
• En virtual.c, un malloc de 8 GiB subió VmSize a 8,4 GB sin mover VmRSS; escribir 100 MiB lo llevó a 104 MB. La RAM se entrega al tocar, y por eso hay que comprobar siempre el resultado de malloc.
• La MMU del procesador traduce y comprueba cada acceso; el sistema operativo solo mantiene las tablas e interviene cuando algo se sale de lo normal.
• Utilización de la CPU = 1 − pⁿ. Más procesos en memoria aprovechan mejor la CPU, y el límite es la RAM; de ahí el interés de usarla bien.
• En Linux, free -h, /proc/meminfo, /proc/PID/status y getconf PAGESIZE (4096) permiten observar la memoria.

14. Preguntas de repaso

Intenta responder cada una antes de abrir la respuesta.

Para practicar

1. Compila y ejecuta aislamiento.c varias veces. ¿Cambia la dirección entre ejecuciones? Ejecútalo con setarch -R ./aislamiento, que desactiva la aleatorización, y compara.
2. Modifica aislamiento.c para que imprima también la dirección de una variable local de main y la de un bloque obtenido con malloc. ¿Coinciden esas direcciones entre padre e hijo?
3. Ejecuta proteccion con las direcciones 0, 0x400000 y la dirección de una variable propia (imprímela con otro programa). ¿Cuáles provocan SIGSEGV y cuáles no? Averigua por qué.
4. Ejecuta virtual con 1024, 4096 y 16384 MiB, y mira el resultado de cat /proc/sys/vm/overcommit_memory en tu equipo. ¿A partir de qué tamaño falla el malloc?
5. Modifica virtual.c para que escriba en todo el bloque de a 1 GiB y muestre VmRSS tras cada gigabyte. Hazlo con un tamaño que quepa holgado en tu RAM.
6. Calcula a mano la utilización de la CPU con p = 0,9 para n = 1, 5, 10 y 20, y comprueba los resultados con el simulador. ¿Cuántos procesos hacen falta para pasar del 90 %?
7. Abre /proc/meminfo y localiza MemTotal, MemAvailable y SwapTotal. Compara MemAvailable con la columna free de free -h.