vmalloc, vfree y vzalloc: cuándo usarlo y qué cuesta

vmalloc resuelve un problema concreto: necesitas un búfer grande y contiguo a la vista, pero no te importa que sus páginas anden dispersas por la RAM. A cambio de esa libertad frente a la fragmentación, pagas un peaje que kmalloc no cobra: tablas de páginas propias, entradas de TLB que no se comparten, una reserva más lenta y una liberación diferida. Saber cuándo merece la pena ese peaje es todo el nivel.

La API y cuándo usarla

vmalloc es para reservas grandes cuya contigüidad física a nadie le importa: la memoria de un módulo al cargarse, tablas hash gigantes, búferes de firmware, el área de xt_alloc_table_info de netfilter. La regla práctica: si son más de un par de páginas y no van a alimentar un DMA plano, vmalloc (o mejor kvmalloc, nivel 22.1) es tu asignador.

#include <linux/vmalloc.h>

void *vmalloc(unsigned long size);              /* virtualmente contiguo, sin poner a cero */
void *vzalloc(unsigned long size);              /* idem, memoria a cero */
void *__vmalloc(unsigned long size, gfp_t gfp); /* control fino del contexto de reserva */
void *vmalloc_node(unsigned long size, int nid);/* fija el nodo NUMA de origen */
void  vfree(const void *addr);                  /* libera; acepta NULL sin quejarse */

char *big = vzalloc(16 << 20);   /* 16 MB a cero, virtualmente contiguos */
if (!big)
	return -ENOMEM;
/* ... uso ... */
vfree(big);

Todas estas vías reservan con GFP_KERNEL por dentro y pueden dormir: jamás llames a vmalloc con un spinlock tomado, en un manejador de interrupción ni en ningún contexto atómico. Ese es su primer coste, y el más fácil de olvidar.

Qué ocurre por dentro

Una reserva vmalloc da tres pasos. Primero busca un hueco en la arena virtual de la zona vmalloc y lo reserva como un vm_struct (los rangos libres se gestionan con un árbol rojo-negro de vmap_area). Segundo, pide al buddy allocator las nr_pages páginas de orden cero, una a una, sin exigir que sean vecinas. Tercero, cose esas páginas en el rango virtual reservado escribiendo las entradas de tabla de páginas correspondientes.

/* include/linux/vmalloc.h  (campos principales) */
struct vm_struct {
	struct vm_struct	*next;
	void			*addr;      /* inicio del rango virtual */
	unsigned long		size;
	unsigned long		flags;
	struct page		**pages;    /* el array de paginas sueltas */
	unsigned int		nr_pages;
	phys_addr_t		phys_addr;
	const void		*caller;    /* quien reservo: visible en vmallocinfo */
};

De ahí sale la propiedad que lo define: los marcos físicos están dispersos, así que virt_to_phys no sirve sobre un puntero vmalloc. Para obtener la página real hay que recorrer las tablas de páginas:

struct page *pg = vmalloc_to_page(big + off);  /* camina PGD..PTE; no es una resta */

Puedes auditar cada reserva viva, con su tamaño y su llamante, en /proc/vmallocinfo. Y si ya tienes un array de páginas y solo quieres una vista contigua de ellas, vmap(pages, count, flags, prot) hace justo el tercer paso sin el segundo.

Hay un detalle recursivo que revela por qué la ruta es cara: el propio array pages —los punteros a las nr_pages páginas— es también memoria que hay que reservar, y para reservas enormes ese array puede a su vez necesitar vmalloc. La maquinaria se apoya en parte sobre sí misma, y esa es una de las razones de que su latencia de reserva sea mensurable frente a sacar un objeto de un cache de slab caliente.

El coste, entrada por entrada

El coste de TLB es el más insidioso porque no aparece en el momento de la reserva, sino después, en cada acceso: un búfer vmalloc recorrido intensamente genera fallos de TLB que el mismo búfer en el direct map no tendría. Por eso Linux 7.x, cuando la arquitectura lo permite (CONFIG_HAVE_ARCH_HUGE_VMALLOC), respalda las reservas vmalloc grandes con páginas de tamaño PMD (2 MB) siempre que el tamaño y la alineación lo permitan, reduciendo drásticamente las entradas de TLB. Es automático; se desactiva con el parámetro de arranque nohugevmalloc, y puedes forzarlo con vmalloc_huge(size, gfp).

Queda un coste más, a menudo ignorado: reservar el rango dentro de la arena virtual es una operación serializada. Buscar y apartar el hueco libre pasa por estructuras protegidas, y una tormenta de vmalloc/vfree concurrentes desde muchos núcleos puede convertir la gestión del espacio virtual en un punto de contención. vmalloc no es solo «más lento por acceso»: también escala peor bajo martilleo que un cache de slab por-CPU, que sirve objetos sin tocar estado global.

Lo que vmalloc no puede hacer

No lo pases a un dispositivo que haga DMA a memoria física plana: sus páginas están dispersas y el hardware, que no ve tus tablas de páginas, leería basura contigua. Para eso está el DMA con scatter-gather o dma_alloc_coherent (nivel 27). Tampoco es gratis en 32-bit, donde la zona vmalloc es diminuta y agotarla es un fallo real; en x86-64 la zona mide 32 TB y ese problema desaparece. Y como cada reserva construye tablas de páginas, hacer vmalloc de objetos pequeños en un camino caliente es un despilfarro puro: para eso está el slab.

Vale la pena ver quién usa vmalloc en el árbol real, porque el patrón se repite: reservas grandes, de vida media o larga, sin exigencia de contigüidad física. El cargador de módulos aloja ahí el texto y los datos de cada .ko. El xt_alloc_table_info de netfilter guarda tablas de reglas que pueden ser enormes. Los búferes en anillo de perf, muchas tablas hash dimensionadas en el arranque y el swap_map de cada área de swap viven en vmalloc. Ninguno alimenta un DMA plano; todos serían candidatos a fallar con kmalloc por puro tamaño.