Gerar vários encadernadores de páginas sujos por dispositivo

Question

Nos primeiros 2.6.X kernels, pdflush foi usado e geraria mais pdflush encadeamentos se todos os encadeamentos atuais de pdflush estivessem ocupados por um segundo (leia de Cache de página do Linux e pdflush ).

Como o 2.6.32 kernel, pdflush foi substituído pelos encadeamentos por dispositivo de backup que são nomeados flush-MAJOR (lidos de Linux 2 6 32 - Novatos do Kernel Linux ).

Existe uma maneira de gerar vários flush-MAJOR threads para um único dispositivo de backup?

No momento, estou gravando uma grande quantidade de dados em um disco e, enquanto isso acontece, estou vendo o processo [flush-8:32] em quase 100% de cpu em top . Gostaria de saber se existe uma maneira de gerar mais flush-MAJOR threads para um dispositivo específico que tenha uma carga pesada de E / S. Eu não sei se isso vai ajudar no desempenho, mas eu gostaria de ver o que isso faz.

Eu vi evidências de que vários encadernadores de flusher por dispositivo devem ser suportados em Flushing out pdflush :

After review of the first attempt, Jens added functionality of having multiple flusher threads per device based on the suggestions of Andrew Morton.

Mas não tenho ideia de como fazer isso acontecer ou se acontecer automaticamente e estou sentindo falta dele.

Estou executando o RHEL 6.4 com um kernel 2.6.32-358.el6.x86_64.

    

Answer 1

Você não pode. Costumava haver um bdi_add_flusher_task () que foi descartado por volta de 2009 na iirc. Também foi originalmente planejado para sistemas de arquivos, mas eu não acho que você esteja escrevendo um sistema de arquivos: -)

Mas .. Eu não consigo ver por que você teria 100% de CPU, isso não faz sentido - a menos que você esteja fazendo mais de 10 GB / s em alguma fantástica matriz de $ 100.000. A RAM é muito mais rápida do que o disco, então você deve ter alta CPU, mas não alta.

Corra em cima e veja onde a cpu está sendo usada, e decompõe-a em system, user, irq e aguarde%.

Verifique também se há outros números que aumentam ou atingem status crítico ou de aviso, como verificações de página, etc.

Se for apenas iowait% alto, então isso é esperado, seus discos estão fazendo tudo o que podem e não podem ir mais rápido, e o sistema está apenas esperando que eles leiam ou escrevam blocos.

Editar

Quase esqueci de adicionar essa nota, como Kevin solicitou. Eu tive outra aparência, mas não encontrei nenhuma documentação a respeito de porque eu lembrei que o bdi_add_flusher_task () foi descartado.

Mas ao analisar o código-fonte do Linux 3.2.0-67, esse procedimento não existe, portanto, obviamente ele deve ter sido descartado em algum lugar, embora eu possa facilmente estar errado sobre quando: -)

    

Answer 2

O Jens queria inicialmente adicionar uma função bdi_add_flusher_task () para suportar vários encadernadores de flusher por dispositivo, mas foi abortada após discussão com Christoph Hellwig na lista de e-mail, vendo detalhes do link abaixo: link Assim, vários segmentos de flusher para um único dispositivo nunca foram mesclados na linha principal.