O VirtIO-FS com filas síncronas reduz builds de 7m43s para 5m34s e melhora I/O randômico em 30%. Veja benchmarks, o PR no libkrun e como testar.
O Problema que Todo Mundo Sentia, mas Ninguém Media
O VirtIO-FS, o sistema de arquivos compartilhado que conecta máquinas virtuais (VMs) a um servidor host, sempre foi sinônimo de conveniência.
No entanto, para cargas de trabalho que exigem I/O intensivo, o modelo assíncrono padrão do VirtIO – onde uma requisição é enfileirada, um worker no host a processa e um interrupção avisa a VM – introduzia uma latência perceptível.
Em operações de leitura de arquivos, metadados ou escrita síncrona, a VM muitas vezes ficava ociosa esperando a resposta, enquanto o host realizava o "malabarismo" entre threads e núcleos de CPU.
É exatamente esse gargalo que Sergio López, desenvolvedor da Red Hat, está atacando com uma implementação experimental de filas síncronas (synchronous queues) para o VirtIO-FS.
A proposta, que já está em um pull request (PR) experimental no libkrun (biblioteca de virtualização leve), permite que a thread do host que está executando a vCPU processe a requisição de I/O diretamente, antes de retornar o controle para o guest (a VM).
Os resultados iniciais são, na melhor das hipóteses, impressionantes: um ganho de performance de aproximadamente 30% em tarefas reais.
A Anatomia da Melhoria: Como Funciona a Fila Síncrona
Para entender o ganho, é preciso visualizar o caminho assíncrono. No modelo tradicional, quando a aplicação dentro da VM faz uma chamada de sistema read() ou stat(), o driver VirtIO-FS coloca a requisição em uma fila (virtqueue) na memória compartilhada.
A vCPU então "chuta" a fila, notificando o host (VMM). O host, por sua vez, designa um worker (frequentemente em outro núcleo físico) para processar a requisição no sistema de arquivos real.
Quando o worker termina, ele publica a resposta e dispara uma interrupção de conclusão para a VM. A vCPU, que poderia estar ociosa, é acordada para buscar o resultado.
Todo esse trânsito entre threads e núcleos, somado ao custo de acordar núcleos modernos que entram em estados de baixo consumo (idle), gera uma sobrecarga que, para operações curtas, pode ser maior que o próprio tempo de acesso ao disco.
Com a fila síncrona, o fluxo é radicalmente encurtado. A funcionalidade é negociada através do recurso experimental VIRTIO_FS_F_SYNC. O dispositivo VirtIO-FS passa a oferecer uma fila dedicada e síncrona para cada vCPU configurada.
Quando o guest "chuta" essa fila, a saída da VM (VM exit) leva a thread da vCPU diretamente para dentro da implementação do VirtIO-FS no host. Essa mesma thread realiza a operação no sistema de arquivos do host e já publica a resposta na fila.
Somente depois disso ela retorna para a execução do guest. A VM, ao verificar a fila, encontra o resultado já disponível. Não há troca de contexto entre threads de worker, não há interrupção de conclusão e não há acordar de núcleos ociosos.
Produto Recomendado
Eu ganho uma comissão quando você faz uma compra
Benchmarks: Os Números que Comprovam a Tese
Os testes realizados por López e divulgados em seu blog são o principal argumento a favor da mudança. O benchmark escolhido foi a compilação do libkrunfw (o firmware usado pelo libkrun) em um ambiente Apple M3 Pro. Os resultados falam por si:
- Tempo de build do libkrunfw: Redução de 7 minutos e 43 segundos para 5 minutos e 34 segundos. Isso representa uma melhoria de aproximadamente 28% no tempo total de execução de uma tarefa real e representativa.
- Latência de exclusão de arquivos: A latência média para deletar arquivos caiu 36,1%.
- Throughput de I/O randômico síncrono: A vazão para operações de leitura e escrita aleatórias que aguardam conclusão apresentou melhora significativa, embora o texto original não forneça o percentual exato.
Esses números são particularmente relevantes porque o build de software é uma carga de trabalho que mistura operações de leitura, escrita, criação e exclusão de arquivos – exatamente o tipo de cenário onde o modelo assíncrono impõe sua maior sobrecarga.
O Trade-off e as Considerações de Implementação
Nenhuma otimização vem sem custo. O próprio autor destaca que a abordagem síncrona bloqueia a vCPU durante a operação de I/O. Isso significa que, enquanto a thread está processando a requisição no host, a vCPU não pode executar outras tarefas do guest.
Portanto, a fila síncrona é ideal para operações curtas e bloqueantes, onde a aplicação não tem mais nada a fazer até que o I/O seja concluído.
Para operações longas ou cargas de trabalho com muitas tarefas concorrentes no guest, o modelo assíncrono tradicional pode continuar sendo mais vantajoso. A implementação mantém as filas assíncronas normais e de alta prioridade como opção, permitindo que o guest escolha dinamicamente o melhor caminho.
Status do Projeto e Como Acompanhar
O suporte a VIRTIO_FS_F_SYNC ainda é experimental. Ele está disponível como um pull request (PR) no repositório do libkrun no GitHub (PR #933) e não foi mesclado à versão principal. O código está aberto para revisão e testes pela comunidade.
Para quem deseja se aprofundar nos detalhes técnicos, a análise completa do autor está disponível em seu blog pessoal.
Questionário de Fixação
1. Qual é a principal diferença arquitetural entre a fila assíncrona tradicional e a nova fila síncrona (VIRTIO_FS_F_SYNC) no VirtIO-FS?
Resposta: Na fila assíncrona, um worker no host processa a requisição e uma interrupção avisa a vCPU. Na fila síncrona, a própria thread da vCPU, que está executando no host, processa a requisição de I/O e só retorna ao guest quando o resultado está pronto, eliminando a troca de threads e a interrupção de conclusão.2. Quais foram os ganhos de performance documentados nos testes com o build do libkrunfw?
Resposta: O tempo de build caiu de 7 minutos e 43 segundos para 5 minutos e 34 segundos (melhoria de aproximadamente 28%), e a latência média de exclusão de arquivos foi reduzida em 36,1%.
3. Em quais cenários a fila síncrona NÃO é recomendada, de acordo com o texto?
Resposta: A fila síncrona não é recomendada para operações de I/O longas ou para cargas de trabalho onde o guest tem muitas outras tarefas concorrentes para executar. Nesses casos, o bloqueio da vCPU pode ser prejudicial, e o modelo assíncrono tradicional continua sendo mais vantajoso.
Conclusão: Um Passo Importante para a Virtualização de Contêineres
A virtualização leve, como a proposta pelo libkrun, depende fundamentalmente de um I/O de arquivos eficiente para igualar a experiência de execução de contêineres nativos.
O trabalho de Sergio López demonstra que o VirtIO-FS tem espaço para otimizações arquiteturais profundas.
A redução de quase 30% no tempo de build não é um mero ajuste – é a prova de que o modelo de I/O pode e deve ser adaptado ao padrão de acesso real da aplicação.
Se o PR for adotado, desenvolvedores que usam libkrun ou soluções baseadas nele poderão se beneficiar de um ambiente de desenvolvimento e execução visivelmente mais ágil.
Conclusão
O VirtIO-FS, sistema de arquivos compartilhado para VMs, está prestes a ganhar um reforço significativo de performance com a implementação experimental de filas síncronas no libkrun.
Liderado por Sergio López (Red Hat), o recurso VIRTIO_FS_F_SYNC permite que a thread da vCPU processe diretamente as requisições de I/O no host, eliminando a sobrecarga do modelo assíncrono.
Os testes mostram uma redução de 28% no tempo de build do libkrunfw (de 7m43s para 5m34s) e uma queda de 36,1% na latência de exclusão de arquivos. O código está disponível como um pull request experimental e promete beneficiar especialmente cargas de trabalho com operações de arquivo curtas e bloqueantes.
Nenhum comentário:
Postar um comentário