Queda de desempenho em pipes do Linux

vmsplice é rápido demais

• Alguns programas usam uma chamada de sistema chamada vmsplice para mover dados mais rapidamente por pipes
• Foi observado que os pipes do Linux são mais lentos do que o esperado quando vmsplice não é usado
• Um programa para codificar/decodificar código Morse rapidamente está sendo desenvolvido, e ele usa pipes para isso

Escrevendo dados em um ambiente ideal

• O programa abaixo copia dados sem chamadas de sistema
• Usando AVX-512, ele roda a 167 GB/s
• Mesmo ao desativar o AVX-512 e testar com AVX2 e SSE2, foi registrada a mesma velocidade (167 GB/s)
• É possível atingir 167 GB/s desde que a vetorização seja usada

Escrevendo dados em um pipe de verdade

• Foi escrito e medido um programa que grava dados em um pipe, e o resultado foi uma velocidade de 17 GB/s
• Isso é 10 vezes mais lento do que gravar em um buffer
• O profiling mostrou que a maior parte do tempo é gasta nas chamadas write
• Na função pipe_write, muito tempo é gasto alocando páginas de memória
• A cópia de dados em si representa apenas 20% do tempo de CPU, mas ainda assim é duas vezes mais lenta que __memset_avx512_unaligned_erms

A ajuda do vmsplice

• vmsplice move buffers do espaço do usuário para o kernel sem copiá-los
• Com vmsplice, é possível atingir 210 GB/s
• vmsplice contorna a parte cara da chamada de sistema write

Conclusão

• Escrever em pipes é 10 vezes mais lento do que escrever em memória bruta
• Isso acontece por causa do custo de bloquear buffers e de salvar e restaurar o contexto SIMD
• splice e vmsplice evitam esses custos e movem dados de forma eficiente

Resumo do GN⁺

• Este artigo explica como maximizar o desempenho de pipes no Linux usando vmsplice
• vmsplice melhora muito o desempenho ao mover os dados diretamente, sem copiá-los para o espaço do kernel
• É útil para programas de processamento de dados em alta velocidade, como codificação/decodificação de código Morse
• Outros projetos com funcionalidades parecidas incluem splice e sendfile

[GN⁺]

Opiniões do Hacker News

• O motivo de JMP não ser substituído por RET é a opção CONFIG_RETHUNK

  • Na desmontagem do objdump, é possível ver o resultado em que RET foi substituído por JMP __x86_return_thunk
  • Links relacionados: link1, link2

• As instruções NOP no início e no fim da função permitem que o ftrace insira instruções de rastreamento

  • Elas vêm das macros ASM_CLAC e ASM_STAC
  • Se X86_FEATURE_SMAP for detectado, em tempo de execução elas são preenchidas com as instruções CLAC e STAC
  • Links relacionados: link3, link4, link5

• O side project de um usuário propõe uma system call que fornece um ring buffer para descritores de arquivo

  • Se as duas pontas do pipe suportarem ring buffer, é possível mapear o mesmo ring buffer para viabilizar I/O zero-copy sem chamadas ao kernel
  • Ele está procurando colaboradores
  • Link relacionado: link6

• Chamar os pipes do Linux de "lentos" é como chamar um Toyota Corolla de "lento"

  • Na maioria dos casos, eles são rápidos o suficiente
  • A menos que seja um caso extremo, não há necessidade de procurar algo mais rápido

• Em CPUs modernas, rep movsb é tão rápido quanto a versão vetorizada mais rápida

  • O nome da função do kernel "copy_user_enhanced_fast_string" sugere isso
  • Os recursos de CPU ERMS e FSRM tornam isso possível

• AVX512 consome muita energia e provoca escalonamento de frequência da CPU

  • Links relacionados: link7, link8

• Estamos vivenciando novamente o "hug of death" do Hacker News

  • Graças às páginas em cache do WordPress, a situação melhorou, mas ainda leva alguns segundos

• Seria interessante ver uma versão usando io_uring

  • Com o kernel e buffers pré-compartilhados, seria possível evitar cópias e reduzir o overhead das system calls

• É uma afirmação ousada dizer que o blog leva cerca de 20 segundos para carregar

• Quase toda forma de IPC é "lenta"

  • Foi decidido pagar o custo de desempenho em troca de segurança

• No começo eu não entendia por que o splice era tão lento

  • Foi apontado por que ele é mais lento que o vmsplice, mas ainda não está claro por quê
  • Deve haver algum motivo pelo qual isso não pode ser reimplementado com vmsplice