Qual é o progresso em relação à melhoria do desempenho / capacidade de resposta do sistema durante alta E / S de disco?

Sempre que houver uma E / S de disco alta, o sistema tende a ser muito mais lento e menos responsivo do que o habitual. Qual é o progresso no kernel do Linux em relação a isso? Esse problema está sendo trabalhado ativamente?

Eu acho que na maior parte foi resolvido. Meu desempenho sob IO pesado melhorou na 2.6.36 e espero que melhore mais na 2.6.37. Veja estes artigos do phoronix .

Wu Fengguang e KOSAKI Motohiro publicaram correções nesta semana que acreditam que abordarão alguns desses problemas de capacidade de resposta, para os quais eles chamam de "o sistema fica sem resposta sob pressão de memória e muitas páginas sujas / de write-back". Andreas Mohr, um dos usuários que relatou esse problema ao LKML e testou os dois patches aplicados ao vmscan do kernel. O problema de Andreas foi o sistema ficar totalmente sem resposta (e mudar para um VT levou mais de 20 segundos) ao criar um sistema de arquivos EXT4 quando uma unidade de estado sólido foi conectada via USB 1.1. Em seu sistema, ao escrever 300 milhões a partir do arquivo / dev / zero, o problema era ainda pior.

Aqui está um link direto para o bug

Também de Phoronix

Felizmente, a partir de nossos testes e dos relatórios de outros usuários do Linux que procuram ver esse problema corrigido, os patches vmscan relativamente pequenos que foram publicados parecem resolver melhor o problema. A interface do usuário (GNOME no nosso caso) ainda não é 100% fluida se o sistema estiver sustentando uma quantidade impressionante de atividade do disco, mas certamente é muito melhor do que antes e o que é encontrado até agora no kernel Linux 2.6.35.

Há também o anúncio de lançamento do Phoronix 2.6.36

Parece que as barreiras dos blocos estão desaparecendo e isso também deve ajudar no desempenho.

Na prática, as barreiras têm uma reputação desagradável por reduzir o desempenho de E / S de blocos, a ponto de os administradores serem frequentemente tentados a desligá-los e assumir seus riscos. Embora as operações de fila com tags fornecidas pelo hardware contemporâneo devam implementar barreiras razoavelmente bem, as tentativas de fazer uso desses recursos geralmente têm dificuldades. Portanto, no mundo real, as barreiras são implementadas simplesmente drenando a fila de solicitações de E / S antes da emissão da operação de barreira, com algumas operações de liberação ativadas para que o hardware efetivamente comprometa os dados na mídia persistente. As operações de drenagem de fila paralisam o dispositivo e eliminam o paralelismo necessário para o desempenho total; não é de surpreender que o uso de barreiras possa ser doloroso.

Há também este artigo do LWN sobre programação justa de E / S

Eu diria que o IO despertou muito sobre o tempo do lançamento do ext4 na versão 2.6.28. Os links a seguir são para versões Linux Kernel Newbies Kernel, você deve revisar as seções Block e Filesystems. É claro que isso pode ser um sentimento injusto, ou apenas na época em que comecei a assistir o desenvolvimento do FS, tenho certeza de que ele vem melhorando o tempo todo, mas sinto que alguns dos problemas do ext4 'fizeram com que as pessoas olhassem bastante para a pilha de IO, ou pode ser que eles esperassem que o ext4 resolvesse todos os problemas de desempenho e, quando não perceberam, precisaram procurar em outros lugares os problemas.

2.6.28 , 2.6.29 , 2.6.30 , 2.6.31 , 2.6.32 , 2.6.33 , 2.6.34 , 2.6.35 , 2.6.36 , 2.6.37