Como eu testo o efeito de ionice (contra um dispositivo usando o planejador cfq)?

Question

Estou tentando construir um experimento para medir o efeito da ionização. O que eu gostaria de fazer é (por outra resposta no serverfault ) causar freqüente o suficiente E / S que um processo suficientemente "aguçado" é privado de qualquer E / S.

Com base em outra resposta no serverfault , acho que preciso causar pelo menos uma operação real de E / S para um dispositivo comum planejado com cfq a cada 250ms. Meu pensamento foi escrever um programa trivial que tem um loop que

• grava em um arquivo (configurável) no dispositivo comum,
• faz um fsync() (para forçar uma operação de E / S definida),
• usa usleep() para atrasar uma quantidade configurável de tempo
• periodicamente usa lseek() para truncar o arquivo (para que eu não preencha o sistema de arquivos)

Eu então inicio uma instância do programa usando ionice -c3 ( idle classe de agendamento) em um arquivo no dispositivo comum. Eu simultaneamente executo várias instâncias com a classe de agendamento padrão ( best-effort ), especificando um arquivo diferente no dispositivo comum (variando os valores de atraso).

Minha hipótese era de que, para valores de atraso de 250 ms ou mais no processo de "melhor esforço", eu veria o progresso feito pelo processo "ocioso"; para valores inferiores a 250 ms, veria pouco ou nenhum progresso feito pelo processo "inativo".

Minha observação foi que não houve diferença no desempenho dos dois processos; ambos fizeram progressos semelhantes. Só para ter certeza (no caso das indicações de relógio de parede que o processo de "melhor esforço" estava realizando I / O muito mais rápido do que a cada 250ms), iniciei várias instâncias simultâneas do processo "best-effort", especificando não (zero) demora. Ainda assim, não vi diferença no desempenho entre os processos nas duas classes de agendamento.

Só para ter certeza, verifiquei novamente a classe do agendador:

$ cat /sys/block/xvda/queue/scheduler
noop anticipatory deadline [cfq] 

O que é que estou perdendo sobre como o scheduler cfq funciona?

Se for importante, isso está em um kernel 2.6.18.

    

Answer 1

Eu tentaria medir o efeito usando um gerador de carga como stress -i n ou stress -d n , onde "n" é o número de processos. Execute isso em uma janela. Tente nmon ou iostat em outro e tente um processo de aplicação representativo no mesmo dispositivo de bloco. Veja como o tempo de serviço é alterado em iostat com várias configurações de ionização (ou teste a resposta de dentro do seu aplicativo).

Quanto à cfq, parece haver mudanças durante o ciclo de vida do RHEL5 (em 2.6.18). Foi perceptível nos servidores de aplicativos que precisei migrar para os noop e deadline elevators por causa de problemas de contenção.