Come abilitare e utilizzare lo scheduler BFQ?

Ho appena installato il kernel Linux versione 4.12 su Ubuntu 17.04 usando ukuu (Ubuntu Kernel Update Utility https://doc.ubuntu-fr.org/ubuntu_kernel_upgrade_utility ).

Il fatto è che, quando controllo gli scheduler I / O disponibili, non riesco a trovare il BFQ né lo scheduler I / O Kyber:

cat /sys/class/block/sda/queue/scheduler
> noop deadline [cfq]

Quindi, come utilizzare uno dei nuovi programmatori in questa versione di Linux?

linux-kernel scheduling

— Sidahmed
fonte

Non sono su Ubuntu, ma quello che ho fatto in Fedora potrebbe esserti di aiuto.

BFQ è uno scheduler blk-mq (Meccanismo di accodamento IO a blocchi multi-coda), quindi è necessario abilitare blk-mq all'avvio, modificare il file / etc / default / grub e aggiungere scsi_mod.use_blk_mq=1al proprio GRUB_CMDLINE_LINUX, questo è il mio file grub, come un esempio:

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"

Successivamente, è necessario aggiornare grub. Su Fedora dobbiamo usare sudo grub2-mkconfig -o /path/to/grub.cfg, che varia a seconda del metodo di avvio . Su Ubuntu, puoi semplicemente eseguire:

sudo update-grub

Riavvia e se ottieni questo:

cat /sys/block/sda/queue/scheduler
[mq-deadline] none

Probabilmente il tuo kernel è stato compilato con BFQ come modulo , e questo può valere anche per Kyber.

sudo modprobe bfq
sudo cat /sys/block/sda/queue/scheduler
[mq-deadline] bfq none

Puoi aggiungerlo all'avvio aggiungendo un /etc/modules-load.d/bfq.conffile contenente bfq.

È importante notare che abilitando blk_mq diventa impossibile utilizzare gli scheduler non blk_mq, quindi perderai noop cfq e la scadenza non mq

Apparentemente il sistema di pianificazione blk_mq non supporta i flag dell'ascensore in grub, al suo posto si possono usare le regole udev, con il vantaggio di offrire un controllo più dettagliato.

Crea /etc/udev/rules.d/60-scheduler.rulesse non esistesse e aggiungi:

ACTION=="add|change", KERNEL=="sd*[!0-9]|sr*", ATTR{queue/scheduler}="bfq"

Come indicato qui, se necessario, è possibile distinguere tra dispositivi rotazionali (HDD) e non rotazionali (SSD) nelle regole udev utilizzando l'attributo ATTR{queue/rotational}. Essere consapevoli del fatto che Paolo Valente, BFQ sviluppatore, ha sottolineato in LinuxCon Europa, che BFQ può essere una scelta migliore rispetto al noopo deadlinescheduler in termini di garanzie a bassa latenza, ciò che rende un buon consiglio di usarlo per gli SSD troppo.

Confronto di Paolo: https://www.youtube.com/watch?v=1cjZeaCXIyM&feature=youtu.be

Salvalo, ricarica e attiva udev rules:

sudo udevadm control --reload
sudo udevadm trigger

— RomuloPBenedetti
fonte

Voglio solo notare: non farlo su computer con Linux <4.15 che ti aspetti di essere in grado di sospendere su RAM; <4.15 bloccherà tutti gli I / O al curriculum perché mancano delle correzioni "quiescing SCSI sicuro".

— Ivan Kozik,

Potresti anche avere problemi sul kernel 4.14 in cui l'abilitazione di blk-mq sembra dare un kernel "oops" all'inizio del caricamento del kernel su alcuni sistemi (non è un panico completo, ma solo una null nullità all'interno del kernel). Potresti perderlo se non lo stai cercando, ma se sei paranoico potrebbe essere un segno che qualcosa è rotto.

— CR.

Suggerirei di usare una regola udev leggermente più accurata. Quando ho provato quello mostrato qui, udev ha provato a impostare lo scheduler per alcuni dispositivi i cui nomi corrispondono a quel modello, ma non sono dispositivi a blocchi SCSI che possono usare lo scheduler BFQ. La regola con cui sono finito è questa: ACTION=="add|change", SUBSYSTEM=="block", DRIVERS=="sd|sr", ATTR{queue/scheduler}!="bfq", ATTR{queue/scheduler}="bfq"evita la corrispondenza dei modelli rispetto ai nomi dei dispositivi, il che rende la corrispondenza più accurata. Non corrisponderà ai dispositivi di partizione perché non hanno l'attributo "coda / scheduler".

— Dan Molding

È anche importante notare che i kernel 4.15-4.16 soffrono di un bug piuttosto grave in cui l'aggiornamento dello schema di partizione di un'unità durante l'utilizzo di BFQ può portare a un blocco I / O completo. Cfr .: lkml.org/lkml/2017/12/1/80

— Glutanimate,

Per estendere la grande risposta di RomuloPBenedetti :

È possibile verificare se lo scheduler bfq è effettivamente disponibile su un determinato dispositivo utilizzando la PROGRAM=="/bin/grep -E -q '(^|[[:space:]])bfq($|[[:space:]])' '$sys$devpath/queue/scheduler'"regola udev. Questo sostituirà efficacemente DRIVERS=="sd|sr"e semplicemente non sparerà se uno ha dimenticatoscsi_mod.use_blk_mq=1

curiosità:

PROGRAM- Eseguire un programma per determinare se esiste una corrispondenza; la chiave è vera se il programma ritorna correttamente; Se non viene fornito alcun percorso assoluto, il programma dovrebbe vivere in / lib / udev.
$sys- Il punto di montaggio sysfs ( /sys).
$devpath - Il devpath del dispositivo (/ devices / pci / ...).

— Arano-kai
fonte