O que o Fedora Workstation 29 usa como escalonador de E / S padrão?

Question

Se depender do tipo exato de dispositivo de bloco, qual é o agendador de E / S padrão para cada tipo de dispositivo?

Informações básicas

O Fedora 29 inclui um kernel Linux da série 4.19. (Tecnicamente, o lançamento inicial usava um kernel da série 4.18. Mas um kernel 4.19 é instalado pelas atualizações normais de software).

A partir da versão 4.19, o kernel da linha principal tem CONFIG_SCSI_MQ_DEFAULT as default y . Ou seja é o que você obtém se você pegar a árvore publicada pelo Linus, sem aplicar nenhum patch específico do Fedora. Por padrão, os dispositivos SCSI e SATA usarão a nova camada de bloqueio de várias filas. (O Linux trata os dispositivos SATA como sendo SCSI, usando uma tradução baseada no padrão SAT ).

Este é um passo de transição para remover o código antigo. A programação mais recente é remover o código antigo na versão 4.21 , ou seja, a próxima janela de mesclagem. / p>

No novo sistema MQ, os dispositivos de bloco usam um novo conjunto de agendadores de E / S. Estes incluem none , mq-deadline e bfq . No kernel 4.19 da linha principal, o agendador padrão é definido da seguinte maneira:

/* For blk-mq devices, we default to using mq-deadline, if available, for single queue devices. If deadline isn't available OR we have multiple queues, default to "none". */

Uma sugestão foi feita para usar o BFQ como o padrão no lugar de mq-deadline . Esta sugestão não foi aceita para 4.19.

Para a camada de bloco SQ legada, o agendador padrão é CFQ, que é mais semelhante ao BFQ.

= > O agendador de E / S padrão do kernel pode variar, dependendo do tipo de dispositivo: SCSI / SATA, MMC / eMMC, etc.

O CFQ tenta suportar algum nível de "justiça" e prioridades de E / S ( ionice ). Tem várias complexidades. O BFQ é ainda mais complexo; Ele suporta ionice , mas também tem heurística para classificar e priorizar I / O automaticamente. O deadline style scheduling é mais simples; não suporta ionice .

= > Os usuários com a configuração de kernel padrão do Linux, dispositivos SATA e nenhuma política de espaço de usuário adicional (por exemplo, sem regras udev ) estarão sujeitos a uma mudança de comportamento no 4.19. Onde ionice costumava funcionar, não terá mais efeito algum.

No entanto, o Fedora inclui patches / configurações específicas do kernel. O Fedora também inclui políticas do espaço do usuário, como as regras padrão udev .

O que o Fedora Workstation 29 usa como o agendador de E / S padrão? Se depender do tipo exato de dispositivo de bloco, qual é o agendador de E / S padrão para cada tipo de dispositivo?

    

Answer 1

O Fedora 29 vem com o kernel 4.18.16 . Parece que CFQ é o padrão.

$ grep CONFIG_DEFAULT_IOSCHED= /boot/config-4.18.16-300.fc29.x86_64 
CONFIG_DEFAULT_IOSCHED="cfq"
$ grep CONFIG_SCSI_MQ_DEFAULT /boot/config-4.18.16-300.fc29.x86_64 
# CONFIG_SCSI_MQ_DEFAULT is not set
$ cat /sys/block/sda/queue/scheduler
noop deadline [cfq] 

No momento da redação deste artigo (24 de novembro de 2018), o 4.19.3 está disponível como atualização para o F29. Mas as opções de configuração não parecem ter mudado.

4.20.0 (RC1) está na árvore de desenvolvimento "Rawhide". Nesse kernel do devel-tree, CFQ ainda é padrão, e CONFIG_SCSI_MQ_DEFAULT ainda está indefinido. A lista do Kernel do Fedora em link é o melhor lugar para discutir se isso deve mudar.

    

Answer 2

Algumas informações que podem ser úteis para sua escolha

Sou um dos autores do BFQ, então sou uma festa desinteressada :) Mas vou relatar apenas números obtidos com testes repetitivos.

Testamos o BFQ em cartões SD, eMMC, HDDs, SSDs SATA, e NVMe SSDs. Quanto aos HDDs e SSDs, executamos testes com ambos configurações de disco único e RAID.

Em termos de taxa de transferência, os resultados podem ser resumidos da seguinte forma. Com SD Cards, eMMC e HDDs (single e RAID), não há regressão em termos de rendimento. Em contraste, com os HDDs, há um ganho em torno 20-30% com alguma carga de trabalho.

Em SSDs, há uma perda de throughput somente

• com E / S de sincronização aleatória: cerca de 2-3% em SSDs médios, até 10-15% em SSDs NVMe muito rápidos. Com uma carga de trabalho destinada a colocar o BFQ condição difícil, chegamos a uma perda de 18% [1], mas em qualquer outra teste de terceiros a perda é de cerca de 10% no pior dos casos. Esta perda é principalmente devido ao fato de que o BFQ não é um planejador de I / O mínimo. Nós estão trabalhando nisso. Não é fácil; vamos precisar de tempo para preencher este lacuna.
• com E / S de gravação única em SSDs muito rápidos: cerca de 5 a 10%. Isto é devido a um problema com tags de solicitação de E / S. Nós já encontramos uma solução. Como não consideramos esse problema crítico, estamos dando mais prioridade para outros itens em nossa lista TODO. Se você pensa o contrário, nós estão dispostos a mudar nossas prioridades.

Devido à sobrecarga acima, o BFQ não pode processar mais de 400 a 500 KIOPS em uma CPU de commodity.

Em termos de capacidade de resposta e latência para aplicativos sensíveis ao tempo (como players de áudio / vídeo), os resultados são simplesmente incomparáveis. Para exemplo, independentemente da carga de trabalho de E / S em segundo plano, com BFQ os aplicativos são iniciados tão rapidamente quanto se a unidade estivesse inativa. Com qualquer um dos outros agendadores, os pedidos podem levar dez vezes mais tempo, ou mesmo não começar de todo (até a carga de trabalho de fundo terminar) [1].

Além disso, quanto às cargas de trabalho semelhantes a servidor, o BFQ permite, por exemplo, que a fração desejada da largura de banda de E / S seja garantida a cada cliente (ou contêiner, VM ou qualquer outro tipo de armazenamento de compartilhamento de entidade), atingindo um throughput total não comparável ao alcançado por qualquer outra solução para o controle de E / S [2].

Finalmente, se você estiver em dúvida sobre alguma carga de trabalho específica, nós fique feliz em testá-lo.

[1] link

[2] link