Acabei de instalar o kernel do Linux versão 4.12 no Ubuntu 17.04 usando o ukuu (Utilitário de Atualização do Kernel do Ubuntu https://doc.ubuntu-fr.org/ubuntu_kernel_upgrade_utility ).
O fato é que, quando verifico os agendadores de E / S disponíveis, não consigo encontrar o BFQ nem o agendador de E / S Kyber:
cat /sys/class/block/sda/queue/scheduler
> noop deadline [cfq]
Então, como usar um dos novos agendadores nesta versão do Linux?
Respostas:
Não estou no Ubuntu, mas o que fiz no Fedora pode ajudá-lo.
O BFQ é um agendador blk-mq (Mecanismo de enfileiramento de E / S de blocos com várias filas), portanto, você precisa ativar o blk-mq no momento da inicialização, editar seu arquivo / etc / default / grub e adicionar scsi_mod.use_blk_mq=1ao seu GRUB_CMDLINE_LINUX, este é o meu arquivo grub, como um exemplo:
GRUB_TIMEOUT=3
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=false
GRUB_HIDDEN_TIMEOUT_QUIET=true
GRUB_TERMINAL_OUTPUT="console"
GRUB_CMDLINE_LINUX="quiet vt.global_cursor_default=0 scsi_mod.use_blk_mq=1"
GRUB_DISABLE_RECOVERY="true"
Depois disso, você deve atualizar seu grub. No Fedora, temos que usar sudo grub2-mkconfig -o /path/to/grub.cfg, o que varia dependendo do método de inicialização . No Ubuntu, você pode simplesmente executar:
sudo update-grub
Reinicie e, se você obtiver isso:
cat /sys/block/sda/queue/scheduler
[mq-deadline] none
Provavelmente, seu kernel foi compilado com o BFQ como um módulo , e esse também pode ser o caso do Kyber.
sudo modprobe bfq
sudo cat /sys/block/sda/queue/scheduler
[mq-deadline] bfq none
Você pode adicioná-lo no momento da inicialização adicionando um /etc/modules-load.d/bfq.confarquivo que contém bfq.
É importante observar que a ativação do blk_mq impossibilita o uso de agendadores que não sejam do blk_mq, para que você perca noop cfq e o prazo não mq
Aparentemente, o sistema de agendamento blk_mq não suporta sinalizadores de elevador no grub, as regras do udev podem ser usadas, com o bônus de oferecer um controle mais granular.
Crie /etc/udev/rules.d/60-scheduler.rulesse não existir e adicione:
ACTION=="add|change", KERNEL=="sd*[!0-9]|sr*", ATTR{queue/scheduler}="bfq"
Como apontado aqui , se necessário você pode distinguir entre rotacionais (HDDs) e (SSDs) dispositivos não-rotacionais em udev regras usando o atributo ATTR{queue/rotational}. Esteja ciente de que Paolo Valente, colaborador BFQ, apontado na LinuxCon Europe que BFQ pode ser uma escolha melhor do que o noopou deadlineprogramadores em termos de garantias de baixa latência, o que faz um bom conselho para usá-lo para SSDs também.
Comparação de Paolo: https://www.youtube.com/watch?v=1cjZeaCXIyM&feature=youtu.be
Salve e recarregue e ative udev rules:
sudo udevadm control --reload
sudo udevadm trigger
ACTION=="add|change", SUBSYSTEM=="block", DRIVERS=="sd|sr", ATTR{queue/scheduler}!="bfq", ATTR{queue/scheduler}="bfq"evita a correspondência de padrões com os nomes dos dispositivos, o que torna a correspondência mais precisa. Ele não corresponde aos dispositivos de partição porque eles não têm o atributo "fila / agendador".
Para estender uma ótima resposta de RomuloPBenedetti :
Você pode testar se o agendador bfq está realmente disponível em um dispositivo específico usando a PROGRAM=="/bin/grep -E -q '(^|[[:space:]])bfq($|[[:space:]])' '$sys$devpath/queue/scheduler'"regra udev. Isso efetivamente substituirá DRIVERS=="sd|sr"e não disparará se você esquecerscsi_mod.use_blk_mq=1
Curiosidades:
PROGRAM- Execute um programa para determinar se há uma correspondência; a chave é verdadeira se o programa retornar com sucesso; Se nenhum caminho absoluto for fornecido, espera-se que o programa viva em / lib / udev.$sys- O ponto de montagem sysfs ( /sys).$devpath - O caminho do dispositivo (/ devices / pci / ...).