Linux I/O Scheduling overview

Transcript

1 Linux I/O Scheduling overview Roberto Vela 09/11/2013

2 Roadmap Perché lo scheduling? Perché lo scheduling dell'i/o è importante? Principi dello scheduling I/O Scheduling del disco Disk scheduling su Linux Cambiare l'algoritmo di scheduling Cenni => una descrizione accurata dell'argomento richiederebbe diverse ore

3 Perché lo scheduling? To schedule = programmare (come un appuntamento) Spesso le risorse non sono sufficienti per soddisfare tutte le richieste Il Sistema Operativo ha il ruolo di assegnare le risorse ai processi che le richiedono

4 Perché lo scheduling I/O è importante? I tempi di accesso alle periferiche di I/O tipicamente sono di ordini di grandezza più grandi di quelli della CPU o di accesso alla memoria centrale Collo di bottiglia per le performance dell'intero sistema

5 Tipi di periferiche di I/O A blocchi E' possibile trasferire solo insiemi di dati di una precisa dimensione. A caratteri Vengono trasferiti flussi continui di dati.

6 Tecniche di gestione dell'i/o I/O Programmato I/O ad Interrupt Direct Memory Access (DMA)

7 Principi della gestione dell'i/o Efficienza: l'i/o non deve pesare sulle prestazioni del sistema Imparzialità Generalità

8 Scheduling del disco Fra le periferiche di I/O, la memoria secondaria è cruciale per le prestazioni: Maggioranza dei dati salvata su disco Swapping pagine di memoria File di spool periferiche virtuali

9 Struttura di un disco rigido Un blocco = N settori

10 Scheduling del disco Cosa ci interessa? Equità Throughput (richieste / unità di tempo) Latenza Parametri prestazionali Tempo di seek Ritardo rotazionale Tempo di trasferimento dati

11 FCFS First Come First Served FIFO : le richieste sono servite nell'ordine di arrivo Throughput basso, seek time può essere elevato Usura della testina In base a questo problema potrei usare una tecnica LIFO, però se arrivano troppe richieste potrei avere starvation (ovvero attesa indefinita) di quelle precedenti!

12 SCAN Algoritmo dell'ascensore Servo tutte le richieste lungo la direzione corrente Arrivato alla fine inverto la direzione della testina Pro: throughput decente Svantaggi Starvation richieste su settori già letti se arrivano molte nuove richieste nella direzione corrente Tempo di attesa dipendente dalla traccia Non sfrutta la località delle richieste Molte varianti

13 Scheduling del disco in Linux Applicazione dei principi visti in precedenza Differenze nelle successive versioni del kernel Documentazione file di tuning dispositivi a blocchi: /Documentation/block/queue-sysfs.txt

14 Linus Elevator Usato fino alla versione 2.4 Sì, ha davvero creato uno scheduler con il suo nome Analogo a SCAN Richieste inserite in una coda Merging: richieste di settori vicini uniti in una sola (front merging e back merging) Sorting: richieste ordinate in maniera crescente il base al relativo settore Buon throughput globale

15 Linus Elevator Poca equità: molte richieste vicine portano a starvation (esempio: scrittura di un file) Soluzione tampone: se ci sono richieste in attesa da più di un certo tempo, una nuova verrà posta in fondo alla coda non esaustiva, potrei comunque avere tempi di attesa lunghi Letture sincrone al processo, scritture asincrone =>Writes-starving-reads

16 Deadline (kernel 2.6) Una coda con merge e sort come in Linus elevator Due code FIFO (una per scritture ed una per letture) Ogni richiesta viene messa nella coda ordinata ed in una delle due Se gli elementi in testa delle code FIFO sono in attesa per più di un certo tempo, vengono prelevati Tempi diversi per coda scritture e letture (di un ordine di grandezza circa) risolvo writes starving reads! Dettagli in /Documentation/block/deadline-iosched.txt

17 Anticipatory (fino al kernel ) Deadline può portare ad un basso throughput: i tempi di seek possono essere elevati se le richieste sono lontane! Soluzione: uso di euristiche per determinare se ci saranno nuove richieste nella stessa area del disco ed eventuale attesa senza muovere la testina (es. lettura di più dati contigui in seguito ad elaborazioni del processo)

18 CFQ Completely Fair Queueing Sostituisce Anticipatory dal kernel Più generale, può comportarsi come anticipatory Complesso, richiede una quantità discreta di risorse Mantiene una coda di richieste di I/O sincrone per ogni processo (<=64) Unisce in code le richieste asincrone in base alla priorità dei rispettivi processi Ad ogni ciclo, serve un numero quantum di richieste di ogni coda, in successione.

19 CFQ Completely Fair Queueing Le richieste vengono messe in una nuova coda, sulla quale si fanno il merge ed il sort per minimizzare i tempi di seek Il tempo di accesso fornito ad ogni processo dipende dalla sua priorità. Tunabile con ionice Dettagli in /Documentation/block/cfq-iosched.txt Diversi parametri (/sys/block/sda/queue/iosched)

20 No-op Strategia FIFO Semplice, riduce l'overhead del sistema operativo: il minor numero di istruzioni CPU per effettuare merging e sorting A meno di ottimizzazioni ad altri livelli (es. controller sofisticati) fornisce un basso throughput per carico elevato

21 Come scelgo l'i/o scheduler? Host di VM, grossi sistemi enterprise: CFQ/DEADLINE Piccoli sistemi/dischi lenti: CFQ->NOOP Macchine virtuali: CFQ->NOOP/DEADLINE SSD: non ho dischi! CFQ->NOOP In generale, CFQ offre buone prestazioni in svariati scenari Non esiste un'unica scelta ottimale!

22 Qual è il mio I/O scheduler? Dettagli nella relativa documentazione del kernel: /linux-stable/documentation/block/switching-sched.txt

23 Modificare l'i/o scheduler Per uno specifico dispositivo: Nel bootloader: Compilando il kernel: Sudo make menuconfig Enable the block layer IO Schedulers Default I/O Scheduler (<default>)

24 Domande?

25 Grazie per l'attenzione!

26 Riferimenti The Linux Kernel sourcel Documentation id=head Choosing an I/O Scheduler for Red Hat Enterprise Linux 4 and the 2.6 Kernel IBM Linux Documentation: Best practices for block I/O performance pblockioperf.htm Domenico Cotroneo, Marcello Cinque: Dispensa didattica su I/O e gestione dei dischi -