Perché Ubuntu 16.04 imposta tutti gli scheduler IO su "scadenza"?

Ho appena installato Xubuntu 16.04-64bit su una seconda partizione sul mio laptop. Ho notato che a volte sembrava un po 'lento, quindi ho verificato quale scheduler IO stava usando per quell'unità, che risulta essere deadlineper tutte le unità. Ho un paio di SSD e dischi rigidi, quindi so che "scadenza" è la cosa migliore per gli SSD e cfqper i dischi rigidi.

Ho avviato 14.04 su un'altra partizione e sta usando cfqper le unità rotanti e deadlineper l'SSD, come dovrebbe. Inoltre, ho esaminato /etc/udev/rules.dper vedere se 14.04 stava usando una regola per configurare il tipo di unità ma non era lì, quindi presumo che il kernel lo stia facendo.

Quindi mi chiedo se questo è un bug o stanno usando "scadenza" per tutto adesso?

Aggiornamento: il commento che ho scritto su /etc/udev/rules.d è stato un errore. In effetti sto usando una regola udev per cambiare lo scheduler (proprio come la risposta ha sotto) in base al tipo di rotazione da quando ho iniziato a usare un SSD, qualche anno fa. Immagino di aver dimenticato ... di invecchiare. Comunque, uno dei riferimenti che ho usato era wiki di ottimizzazione SSD Debian .

Non sarebbe una buona idea se fosse incluso? Solo un suggerimento!

kernel scheduler

— curt54
fonte

Risposte:

Con il rilascio di 14.04 lo scheduler predefinito per il kernel 3.13 è stato cambiato da CFQ a Deadline .

Non esiste più un kernel server separato e lo sheduler CFQ non è adatto a molti scenari di utilizzo del server, ad esempio timeout di scrittura KVM . Esistono persino regressioni delle prestazioni sul desktop con dispositivi USB .

— NGRhodes
fonte

Grazie per la lettura, molto illuminante! Il problema USB che ho avuto spesso con le schede SD e con il possibile tablet Android in TWRP. In quest'ultimo, si bloccherebbe alla fine per diversi minuti. Il problema KVM non viene mai visualizzato sui miei ospiti VB poiché sono sul mio SSD con scadenza.

— curt54,

Il team del kernel di Ubuntu esegue regolarmente molte analisi di diversi carichi di lavoro simulati su diversi file system e scheduler I / O per farsi un'idea della migliore scelta di scheduler I / O generici. La risposta generale è che non esiste una scelta perfetta dello scheduler I / O per una configurazione generica su tutti i diversi tipi di installazioni per tutti i diversi tipi di media. I punti salienti da ricordare sono:

I sistemi si stanno spostando su SSD, quindi noop o scadenza sono i migliori per questi; noop ha un sovraccarico della CPU inferiore alla scadenza.
CFQ vs Deadline è una chiamata difficile. CFQ consente una maggiore flessibilità. Tuttavia, abbiamo scoperto che per una gamma più ampia di operazioni di I / O simulate, la scadenza ha fornito latenze più basse e un throughput leggermente superiore rispetto a CFQ.
Eseguo regolarmente il benchmark dei kernel (ogni test del kernel richiede 3+ giorni per essere completato) per una gamma di file system e scheduler I / O. Da questo e da altri dati assortiti proviamo a prendere una decisione informata sulla scelta migliore, vedere:

http://kernel.ubuntu.com/~cking/fs-tests/

Ci sono pro / contro in tutti gli scheduler I / O, quindi qualsiasi default non è perfetto e il team del kernel Ubuntu è sempre disposto ad avere input per la scelta predefinita se dati convincenti e ragioni ci mostrano di cambiare diversamente.

— Colin Ian King
fonte

Siamo passati all'utilizzo di CFQ come predefinito per il kernel Ubuntu Zesty 4.10 e abbiamo anche abilitato il nuovo CONFIG_BLK_WBT_MQ (throttling di writeback multiqueue) in quanto ciò risolve i problemi di writeback della cache sporchi con dispositivi lenti come dispositivi flash.

— Colin Ian King,

Vedremo forse BFQ come predefinito ora che è nel kernel 4.12?

— JauntyDoe

Valuteremo questo per 4.12 / 4.13, ho fatto alcuni primi test anche con Kyber, ma li rivedrò di nuovo una volta che 4.12 uscirà questa settimana.

— Colin Ian King,

In linea di principio questa domanda riguarda solo il kernel 16.04, ma viene ancora cercata :-). Quindi, ecco un aggiornamento più recente: Ubuntu è tornato a CFQ, abbinando l'impostazione predefinita upstream, in Ubuntu dal 17.04 (zesty) al 18.10 (cosmico) .

— sourcejedi

Ulteriore aggiornamento: Linux ha disabilitato WBT quando si utilizza CFQ o BFQ (almeno per impostazione predefinita), perché non funziona bene insieme. 2) Se si desidera valutare il problema risolto da WBT, penso che sia necessario essere consapevoli che il problema varia a seconda del dispositivo (firmware diverso). Nei risultati del tuo benchmark, non riesco nemmeno a trovare il tipo di dispositivo utilizzato. 3) Sono curioso di sapere la tua descrizione di ciò che WBT risolve. Se si guarda alla lettera di copertura sulla v2 del set di patch WBT, WBT è progettato per gestire tamponata scrive sul veloce Flash, che possono avere code molto profonde, ed evitare di morire di fame i lettori sullo stesso dispositivo.

— sourcejedi,

Non so perché gli sviluppatori abbiano deciso di scegliere deadlinecome scheduler predefinito, forse perché la maggior parte dei nuovi computer viene fornita con un SSD, su cui normalmente sono installati i sistemi. Puoi impostare lo scheduler manualmente in questo modo, nel caso in cui non lo abbia già installato ... install gksu:

Apri un terminale ed esegui:

sudo apt install gksu

Quindi eseguire questo comando:

gksudo gedit /etc/udev/rules.d/60-schedulers.rules

Incolla il seguente testo nel file vuoto e salva il file modificato.

# set cfq scheduler for rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="cfq"

# set deadline scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"

Riavvia il sistema operativo e ora stai utilizzando gli scheduler ottimali per HDD e SSD.

— cl-NETBOX
fonte

Sì, questo è quello che stavo usando, come per il mio aggiornamento nella domanda. Ma penso che dato che oggi è comune avere entrambi i tipi di unità, questa regola dovrebbe essere inclusa in tutte le distribuzioni Linux.

— curt54,