Cuando falta memoria: qué es el reclaim

Abre free -h en un servidor cargado y verás la RAM libre rozando el cero. No es un síntoma: es el diseño. La memoria libre es memoria desperdiciada, así que el kernel la rellena de page cache y, cuando una asignación la reclama, no entra en pánico: la recupera. Casi toda la RAM es, en realidad, una caché que el kernel puede vaciar cuando le conviene. A ese vaciado selectivo lo llamamos reclaim, y vive en mm/vmscan.c.

La RAM libre es RAM desperdiciada

Cuando un proceso lee un archivo, el kernel guarda esas páginas en el page cache por si vuelven a hacer falta. No las suelta al terminar la lectura: las retiene mientras haya sitio, porque una página en RAM ahorra un viaje al disco. El resultado es que, en régimen estacionario, casi toda la RAM está ocupada por cache. Eso aparece como used en algunas herramientas y asusta a quien no conoce el modelo.

La cifra que de verdad importa no es MemFree sino MemAvailable: una estimación de cuánta memoria puede entregarse a una nueva carga sin empujar el sistema al swap, contando la parte del cache que es trivialmente recuperable. Un sistema con MemFree bajo y MemAvailable alto está sano; tiene la RAM trabajando, no ociosa.

grep -E 'MemTotal|MemFree|MemAvailable|Cached|Dirty' /proc/meminfo
# MemTotal:       32725132 kB
# MemFree:          412300 kB   <- casi nada libre: es lo normal
# MemAvailable:   21983764 kB   <- lo que de verdad puedes pedir
# Cached:         20114952 kB   <- page cache recuperable
# Dirty:             48820 kB   <- sucio: exige writeback antes de soltarse

Reclamable frente a no reclamable

El reclaim solo puede recuperar lo que tiene a dónde volver. La memoria de usuario se parte en dos grandes familias con destinos muy distintos:

• Respaldada por archivo (page cache): tiene un origen en disco. Si la página está limpia —idéntica al disco—, reclamarla es gratis: se descarta y punto. Si está sucia, hay que escribirla primero (pageout) y solo entonces liberarla.
• Anónima (heap, pila, mmap privado): no tiene archivo detrás. Para expulsarla, el kernel ha de inventarle un hogar: el swap (nivel 25.4). Sin swap, la memoria anónima es prácticamente irrecuperable, y la presión recae entera sobre el cache de archivo.

Y luego está lo que el reclaim no puede tocar: pilas de kernel, la mayoría de las tablas de páginas, páginas fijadas por mlock (que van a la lista LRU_UNEVICTABLE), páginas pinneadas por DMA y casi todo el slab. La excepción del slab son las cachés reclamables —dentries e inodos— que se vacían por otra vía, los shrinkers.

flowchart TD
RAM[Toda la RAM] --> REC[Reclamable]
RAM --> NOREC[No reclamable]
REC --> FILE[Page cache respaldada por archivo]
REC --> ANON[Anonima heap pila mmap privado]
FILE --> LIMPIA[Limpia se descarta al instante]
FILE --> SUCIA[Sucia exige writeback antes]
ANON --> SWAP[Necesita swap para expulsarse]
NOREC --> KERN[Pilas de kernel y tablas de paginas]
NOREC --> MLOCK[Paginas mlocked unevictable]

El plan de reclaim: struct scan_control

Toda operación de reclaim viaja dentro de una struct scan_control. Es el cuaderno de bitácora que dice cuánto recuperar, qué permisos tiene el reclaim y con cuánta agresividad debe actuar. Vale la pena leerla porque en sus campos está condensada media política de memoria del kernel:

/* mm/vmscan.c */
struct scan_control {
	/* cuántas páginas debe recuperar esta pasada */
	unsigned long nr_to_reclaim;

	/* el cgroup objetivo, o NULL para el reclaim global */
	struct mem_cgroup *target_mem_cgroup;

	/* coste relativo de reclamar anónimas frente a archivo */
	unsigned long anon_cost;
	unsigned long file_cost;

	unsigned int may_writepage:1;   /* ¿escribir páginas sucias? */
	unsigned int may_unmap:1;       /* ¿desmapear páginas de procesos? */
	unsigned int may_swap:1;        /* ¿expulsar anónimas al swap? */
	unsigned int proactive:1;       /* reclaim adelantado, no por presión */

	s8 order;           /* orden de la asignación que lo disparó */
	s8 priority;        /* prioridad de escaneo: DEF_PRIORITY..0 */
	s8 reclaim_idx;     /* zona más alta que podemos reclamar */
	gfp_t gfp_mask;

	unsigned long nr_scanned;    /* páginas miradas */
	unsigned long nr_reclaimed;  /* páginas recuperadas */
};

El campo clave es priority. Arranca en DEF_PRIORITY (12) y marca cuántas páginas se escanean por vuelta: aproximadamente el tamaño de la lista desplazado a la derecha por la prioridad. Con prioridad 12 se mira una fracción diminuta; si esa pasada no libera bastante, la prioridad baja a 11, luego 10, y cada decremento duplica el número de páginas escaneadas. El reclaim empieza siendo un roce suave y solo se vuelve agresivo si el sistema no cede memoria.

El bucle que endurece la presión

El corazón del reclaim directo es un bucle que va bajando la prioridad hasta conseguir su cuota o agotar los intentos. Simplificado:

/* mm/vmscan.c — do_try_to_free_pages */
do {
	sc->nr_scanned = 0;
	shrink_zones(zonelist, sc);          /* -> shrink_node -> shrink_lruvec */

	if (sc->nr_reclaimed >= sc->nr_to_reclaim)
		break;                       /* ya tenemos bastante */

	/* bajar la prioridad = escanear el doble en la vuelta siguiente */
} while (--sc->priority >= 0);

Bajo shrink_zones se despliega la cascada real: shrink_node() recorre cada nodo NUMA, shrink_lruvec() reparte la presión entre las listas LRU (nivel 25.2), shrink_list() procesa cada lista y shrink_folio_list() decide, folio a folio, si se descarta, se escribe o se conserva. Es en shrink_folio_list donde una página limpia de archivo se libera sin más y una anónima se manda al swap.

Junto a las páginas viajan los shrinkers, el mecanismo con el que los subsistemas ofrecen liberar objetos de slab. Una caché registra sus funciones y el reclaim las llama con presión proporcional a la prioridad:

/* include/linux/shrinker.h — reclamar objetos de slab, no páginas */
struct shrinker {
	unsigned long (*count_objects)(struct shrinker *,
	                               struct shrink_control *sc);
	unsigned long (*scan_objects)(struct shrinker *,
	                              struct shrink_control *sc);
	long batch;
	int seeks;   /* coste de recrear el objeto; DEFAULT_SEEKS = 2 */
};
/* API moderna: shrinker_alloc() + shrinker_register() */

Así se vacían las cachés de dentries e inodos: count_objects dice cuántos hay, scan_objects libera una tanda. Puedes forzarlo a mano escribiendo en /proc/sys/vm/drop_caches, herramienta útil para depurar pero venenosa en producción, porque tira cache caliente que costará releer.