El coste de copiar: por qué cada byte importa

El código más inocente del mundo —leer de un fichero y escribir a un socket— esconde uno de los mayores desperdicios de la programación de sistemas. Cada iteración de ese bucle mueve los mismos bytes cuatro veces por la memoria, dos de ellas quemando la CPU en un memcpy glorificado que no calcula nada. En un servidor a 40 Gbit/s o en una tubería de vídeo 8K, esa copia deja de ser un detalle y se convierte en el cuello de botella. Este nivel entero es aprender a verla y a borrarla.

El camino clásico: cuatro copias por bloque

La versión que todos escribimos primero para servir un fichero por la red parece gratuita. No lo es.

/* Servir un fichero por un socket: la version ingenua */
char buf[65536];
ssize_t n;

while ((n = read(file_fd, buf, sizeof buf)) > 0) {   /* page cache -> buf usuario */
    char *p = buf;
    while (n > 0) {
        ssize_t m = write(sock_fd, p, n);            /* buf usuario -> buf socket */
        if (m < 0)
            return -1;
        p += m;
        n -= m;
    }
}

Sigue el viaje de un bloque de 64 KiB. Son cuatro traslados de memoria:

1. DMA disco → page cache. El controlador de almacenamiento deposita los datos en el page cache del kernel (nivel 24). El motor DMA trabaja solo; la CPU ni se entera.
2. CPU page cache → buffer de usuario. El read invoca copy_to_user: la CPU lee del page cache y escribe en buf. Puro trasiego.
3. CPU buffer de usuario → buffer del socket. El write invoca copy_from_user: la CPU lee de buf y escribe en el sk_buff del socket, otra vez dentro del kernel.
4. DMA buffer del socket → NIC. La tarjeta de red lee su buffer por DMA y pone los bytes en el cable. La CPU, de nuevo, ausente.

A eso súmale cuatro cambios de contexto: cada llamada al sistema cruza usuario→kernel→usuario. Pero lo escandaloso son los pasos 2 y 3: los datos ya vivían en memoria del kernel (el page cache), suben a userspace y bajan de inmediato al kernel otra vez. Nunca necesitaron visitar el espacio de usuario. Ese viaje de ida y vuelta es trabajo inventado.

Anatomía del impuesto: ancho de banda, ciclos y caché

copy_to_user y copy_from_user son las primitivas del kernel para cruzar la frontera de la frontera usuario↔kernel (nivel 12): validan el puntero con access_ok, toleran fallos de página y, por debajo, son un memcpy optimizado.

/* En el lado del kernel, la ruta de 'read' termina copiando al usuario */
if (copy_to_user(ubuf, kaddr, len))   /* CPU: page cache -> espacio de usuario */
    return -EFAULT;

El coste tiene tres caras:

• Ancho de banda de memoria. Cada copia por CPU lee N bytes y escribe N bytes: consume 2N de tráfico en el bus de memoria. A velocidad de línea de 40 Gbit/s, las dos copias suman decenas de gigabytes por segundo de tráfico dedicado únicamente a reubicar datos. Ese ancho de banda no lo tiene ya el resto del sistema.
• Ciclos de CPU. Mientras la CPU copia, no calcula. Un servidor de ficheros o un transcodificador debería estar sirviendo peticiones o transformando fotogramas, no actuando de motor memmove. La copia convierte un núcleo caro en una bomba de bytes tonta.
• Contaminación de caché. Empujar 64 KiB por la CPU desaloja de L1 y L2 el conjunto de trabajo útil. Y lo irónico: esos datos suelen usarse una sola vez —se transmiten y se olvidan—, así que ensucian la caché sin beneficiarse jamás de ella.

Dónde más se esconde la copia

El camino de envío no es el único culpable, y verlo entero desarma la ilusión de que la copia es un problema aislado:

• El lado de recepción es el mismo mal en espejo. Un recv sobre un socket copia del sk_buff del kernel al buffer del proceso (copy_to_user); si luego ese dato pasa a otro subsistema, se vuelve a copiar. La NIC deposita por DMA, y a partir de ahí la CPU vuelve a hacer de mula.
• Los protocolos apilan copias. Cifrar con TLS, serializar un mensaje, reensamblar fragmentos: cada capa que reescribe el dato en un buffer nuevo suma una copia que el perfil no atribuye a la E/S, pero que compite por el mismo ancho de banda de memoria.
• El doble buffer del propio programa. Es habitual leer a un buffer de aplicación y luego copiarlo a otro «de trabajo». Dos copias más, invisibles en el código, evidentes en perf.

La conclusión incómoda: en una ruta de datos real, las cuatro copias del ejemplo son un suelo, no un techo. Contar copias de punta a punta —incluidas las que añaden tus propias capas— es el primer acto de diseño de cualquier sistema que aspire a saturar la red o el disco.

Qué promete zero-copy, y qué no

Zero-copy no significa cero transferencias: significa cero copias intermedias hechas por la CPU. Las transferencias DMA siguen ahí, porque son la E/S real. Lo que desaparece es el trasiego de bytes por el procesador. Hay dos grandes familias de técnicas, y son el mapa de este nivel:

flowchart LR
D[Disco] -->|DMA 1| PC[Page cache del kernel]
PC -->|copy_to_user por CPU| UB[Buffer de usuario]
UB -->|copy_from_user por CPU| SB[Buffer del socket]
SB -->|DMA 2| NIC[Tarjeta de red]
style PC fill:#89b4fa,color:#11111b
style UB fill:#f38ba8,color:#11111b
style SB fill:#f38ba8,color:#11111b
style NIC fill:#a6e3a1,color:#11111b

Las dos cajas rojas son el enemigo. Mapear las funde en una sola región compartida; empalmar las salta pasando referencias de página de un fd al otro. Pero atención a la letra pequeña que este nivel resolverá: el zero-copy no es gratis, cambia copias por complejidad —fijar páginas, rastrear cuándo el hardware terminó, mantener la coherencia de caché— y solo compensa por encima de cierto tamaño de bloque. Regalar la copia pequeña puede salir más caro que hacerla.