Jens Axboe, criador do io_uring e dos planejadores de entrada/saída CFQ, Deadline e Noop, propôs à inclusão no código-fonte do emulador QEMU um patch que reduz de 50 a 80 vezes a latência ao trabalhar com fdmon (monitoramento de descritor de arquivo) no modo «aio=io_uring» e quando o sistema está em estado ocioso.
O problema ocorreu devido à transição da operação ppoll() para um estado de espera com um timeout de 499 ms, apesar da existência de entrada/saída. Para retomar a execução do ciclo principal de processamento de eventos, suspenso pela ppoll(), foi proposto um patch que adiciona à função de criação de entrada SQE (Submission Queue Entry) uma chamada à função aio_notify(), que retira a ppoll() do modo de espera.
O problema surgiu durante os testes de regressão do io_uring com máquinas virtuais dispositivos de bloco diferentes. Jens notou o aparecimento aleatório de timeouts ao usar dispositivos AHCI/SATA no modo «aio=io_uring», enquanto que em configurações com dispositivos virtio-blk ou nvme, os testes sempre terminavam com sucesso em cerca de um segundo. Observa-se que o problema afeta todos os tipos de dispositivos de bloco, mas para os dispositivos AHCI/SATA, a ocorrência de latências é mais marcante devido ao uso de MMIO.
Jens também descreveu sua experiência ao debugar o problema usando o assistente de IA Claude. Após definir um cenário que reproduzisse as condições de ocorrência do timeout, ele forneceu os dados de depuração disponíveis à Claude, deu acesso à máquina virtual e pediu para identificar as prováveis causas da falha identificada.
Claude decidiu verificar se o desempenho diminuiria ao usar o dispositivo virtio-blk e executou com ele o cenário destrutivo proposto pelo desenvolvedor, que reproduzia o problema. Durante a verificação, os primeiros 128 MB do conteúdo do dispositivo de bloco /dev/vda na máquina virtual foram removidos. Após isso, Claude concluiu que o problema não estava no virtio-blk. Quando Jens mencionou ao assistente de IA a remoção de parte do conteúdo do /dev/vda, ele respondeu «Sim, eu fiz isso», e após o pedido para corrigir, restaurou a funcionalidade do disco virtual /dev/vda. Nota-se que o uso do assistente de IA ajudou a entender melhor as particularidades da execução de diferentes ciclos de processamento de eventos no QEMU.
Notavelmente, o problema foi bastante difícil de detectar, pois nos testes sintéticos a lentidão não é registrada devido ao fato de o despertar do ciclo de processamento de eventos com ppoll ser influenciado por outra atividade, e os testes sintéticos de entrada/saída não executam o processamento dos dados recebidos. A lentidão tornou-se mais evidente ao adicionar várias chamadas usleep() para simular o processamento de dados.
Antes da correção no sistema em estado ocioso (idle): time sudo ./iotest /dev/sda Executado em 25.76 secs fish externo usr time 6.19 millis 783.00 micros 5.41 millis sys time 12.43 millis 642.00 micros 11.79 millis
Após a correção no sistema em estado ocioso: time sudo ./iotest /dev/sda Executado em 1.30 secs fish externo usr time 2.14 millis 0.14 millis 2.00 millis sys time 16.93 millis 1.16 millis 15.76 millis
Fonte: opennet.ru
