La degradación del rendimiento de los pipes en Linux

vmsplice es demasiado rápido

• Algunos programas usan una llamada al sistema llamada vmsplice para mover datos más rápido a través de pipes
• Se descubrió que los pipes de Linux son más lentos de lo esperado cuando no se usa vmsplice
• Se está escribiendo un programa para codificar/decodificar código Morse rápidamente, y para ello se están usando pipes

Escribir datos en un entorno ideal

• El programa de abajo copia datos sin llamadas al sistema
• Usando AVX-512, corre a una velocidad de 167 GB/s
• Incluso al desactivar AVX-512 y probar con AVX2 y SSE2, registró la misma velocidad (167 GB/s)
• Mientras se use vectorización, se puede alcanzar una velocidad de 167 GB/s

Escribir datos en un pipe en la práctica

• Se escribió y midió un programa que envía datos a un pipe, y registró una velocidad de 17 GB/s
• Esto es 10 veces más lento que escribir en un búfer
• El perfilado mostró que la mayor parte del tiempo se consume en las llamadas a write
• En la función pipe_write, se gasta mucho tiempo asignando páginas de memoria
• La copia de datos en sí solo ocupa el 20% del tiempo de CPU, pero aun así es dos veces más lenta que __memset_avx512_unaligned_erms

La ayuda de vmsplice

• vmsplice mueve búferes del espacio de usuario al kernel sin copiarlos
• Al usar vmsplice, se puede alcanzar una velocidad de 210 GB/s
• vmsplice evita la parte costosa de la llamada al sistema write

Cierre

• Escribir en un pipe es 10 veces más lento que escribir en memoria sin procesar
• Esto se debe al costo de bloquear búferes y de guardar y restaurar el contexto SIMD
• splice y vmsplice evitan estos costos y mueven los datos de forma eficiente

Resumen de GN⁺

• Este artículo explica cómo maximizar el rendimiento de los pipes en Linux usando vmsplice
• vmsplice mejora mucho el rendimiento al mover datos directamente sin copiarlos al espacio del kernel
• Es útil para programas de procesamiento de datos de alta velocidad, como los de codificación/decodificación de código Morse
• Otros proyectos con funciones similares incluyen splice y sendfile

[GN⁺]

Comentarios de Hacker News

• La razón por la que JMP no se reemplaza por RET es la opción CONFIG_RETHUNK

  • En el desensamblado de objdump se puede ver el resultado donde RET fue reemplazado por JMP __x86_return_thunk
  • Enlaces relacionados: enlace1, enlace2

• Las instrucciones NOP al inicio y al final de la función permiten que ftrace inserte instrucciones de trazado

  • Provienen de las macros ASM_CLAC y ASM_STAC
  • Si se detecta X86_FEATURE_SMAP, en tiempo de ejecución se rellenan con las instrucciones CLAC y STAC
  • Enlaces relacionados: enlace3, enlace4, enlace5

• El proyecto paralelo de un usuario propone una llamada al sistema que ofrece un ring buffer para descriptores de archivo

  • Si ambos extremos del pipe soportan el ring buffer, se puede mapear el mismo ring buffer para permitir I/O de copia cero sin llamadas al kernel
  • Está buscando colaboradores
  • Enlace relacionado: enlace6

• Llamar "lentos" a los pipes de Linux es como llamar "lento" a un Toyota Corolla

  • En la mayoría de los casos son lo suficientemente rápidos
  • A menos que se trate de un caso extremo, no hace falta buscar algo más rápido

• En los CPU modernos, rep movsb es tan rápido como la versión vectorizada más rápida

  • El nombre de la función del kernel "copy_user_enhanced_fast_string" lo sugiere
  • Las capacidades de CPU ERMS y FSRM hacen esto posible

• AVX512 consume mucha energía y provoca escalado de frecuencia del CPU

  • Enlaces relacionados: enlace7, enlace8

• Se está volviendo a experimentar el "hug of death" de Hacker News

  • Gracias a las páginas cacheadas de WordPress la situación mejoró, pero aun así sigue tardando varios segundos

• Sería interesante ver una versión usando io_uring

  • Con el kernel y buffers precompartidos se podrían evitar copias y reducir la sobrecarga de las llamadas al sistema

• Decir que el blog tarda unos 20 segundos en cargar es una afirmación audaz

• Casi cualquier forma de IPC es "lenta"

  • Se decidió pagar el costo de rendimiento a cambio de seguridad

• Originalmente no entendía por qué splice es tan lento

  • Se señaló por qué es más lento que vmsplice, pero no queda claro por qué
  • Debe haber alguna razón por la que no se pueda reimplementar con vmsplice