Lezione T6 Scheduling e dispatching

Transcript

1 Lezione T6 Scheduling e dispatching Sistemi Operativi (9 CFU), CdL Informatica, A. A. 2013/2014 Dipartimento di Scienze Fisiche, Informatiche e Matematiche Università di Modena e Reggio Emilia 1

2 Quote of the day (Meditate, gente, meditate...) If you spend too much time thinking about a thing, you'll never get it done. Make at least one definite move daily toward your goal. Lee Yun Fan ( ) Filosofo, attore, esperto di arti marziali 2

3 CARATTERIZZAZIONE DEI PROCESSI 3

4 User Modello di comportamento (Una visione diversa rispetto all'alternanza Calcolo - Servizio) Durante la sua esecuzione, un processo si alterna in due fasi: fase di elaborazione user o kernel (CPU burst). attesa di I/O o evento (Wait). CPU burst CPU burst CPU burst Kernel CPU burst CPU burst CPU burst Wait 4

5 Processi vincolati alle risorse (Resource boundedness) Un processo si dice vincolato (bound) ad una risorsa (resource) oppure ad un evento (event) se la sua prestazione è correlata direttamente alla disponibilità della risorsa o al verificarsi dell'evento. Se la risorsa scarseggia o l'evento è raro, il processo va a singhiozzo. Più e performante la risorsa oppure più spesso si verifica L'evento, allora tanto più il processo è performante. 5

6 Alcuni esempi di programmi (CPU, disco, rete) CPU. Il programma factor che fattorizza un numero intero è vincolato alla CPU. Disco. Il programma dd che trasferisce dati a blocchi da e verso periferiche è vincolato al disco. Rete. Il programma wget che scarica documenti dal Web è vincolato alla capacità del collegamento di rete. 6

7 Vincoli di interesse: CPU- e I/O-bound (Nell'ambito del corso di SO) Il comportamento di un processo si posiziona sempre fra questi due estremi. Processo CPU-bound. Tende a produrre poche sequenze di CPU burst lunghe. Tende a fare poche richieste di I/O. Processo I/O-bound. Tende a produrre tante sequenze di CPU burst brevi. Tende a fare molte richieste di I/O. 7

8 Vincoli di interesse: CPU- e I/O-bound (Nell'ambito del corso di SO) Processo CPU-bound CPU burst CPU burst CPU burst U K CPU burst CPU burst Processo I/O-bound CB CB CB CB U CB CB CB CB CB CB K Wait Wait Wait 8

9 Quali processi sono più importanti? (Bella domanda; dipende dall'uso che si fa del SO) Sistema desktop. È caratterizzato da elevata interattività con l'utente. Tale interattività si estrinseca in richieste di I/O a periferiche (terminale, disco, rete). Si dovrebbero favorire i processi I/O-bound rispetto a quelli CPU-bound. Sistema di calcolo batch. Duale del sistema desktop: interattività pressoché inesistente, necessità di completare quanti più processi di calcolo possibile. Si preferiscono i processi CPUbound. 9

10 Grado di multiprogrammazione (Quanti processi son stati fatti partire?) Il grado di multiprogrammazione è la somma di due contributi: il numero di processi in esecuzione. il numero di processi pronti per l'esecuzione. Tale numero dipende da due fattori: la frequenza con cui un utente fa partire processi. la frequenza con cui i processi escono. 10

11 Obiettivi del gestore dei processi (Se non sono rigorosamente mantenuti, la macchina performa male) Reggere, nei limiti del possibile, il grado di multiprogrammazione imposto dall'utente senza degradare le prestazioni proprie e dei processi. Favorire i processi giusti per il tipo di SO considerato: Desktop I/O-bound. Server CPU-bound. 11

12 Come conseguire gli obiettivi? ( Lista della spesa ) Schedulatore dei processi. Sceglie il prossimo processo da eseguire in maniera consona al tipo di SO in esecuzione. Dispatcher. Sostituisce in maniera efficiente il PCB del processo attuale con il PCB del processo scelto dallo schedulatore. 12

13 SCHEDULATORE DEI PROCESSI 13

14 Processo A Scenario (Il processo può aspettare o farsi da parte) Un processo in kernel mode ha appena programmato il DMA controller per eseguire una operazione di I/O (lettura). La lettura è bloccante ed il processo non può più proseguire l'esecuzione fino all'ottenimento del dato. User sys_read() Kernel I/O DMA PCB A 14

15 Scenario (Il processo si fa da parte; chi è il prossimo?) Per non lasciare il processore inattivo, deve essere scelto e ripristinato un nuovo processo. Qui entra in gioco lo schedulatore, invocato dalla sys_read() (o chi per lei). Processo A User sys_read() Kernel I/O DMA Schedulatore dei processi PCB A 15

16 Processo A PCB A Scenario (Il prossimo processo è deciso dallo schedulatore) Lo schedulatore dei processi sceglie un processo ritenuto idoneo per l'esecuzione. Possibili criteri: è importante (priorità alta). non esegue da tanto tempo. scelto a caso. scelto circolarmente. User sys_read() I/O DMA Schedulatore dei processi PCB Kernel PCB PCB B... PCB 16

17 Scenario (Lo scheduer fa uso del dispatcher) Lo schedulatore dei processi invoca il dispatcher per sostituire il PCB del processo in esecuzione con il PCB del nuovo processo. A questo punto, il processo B è pronto per continuare l'esecuzione. Processo B User sys_read() Kernel I/O DMA Schedulatore dei processi PCB PCB A... PCB PCB B Dispatcher PCB 17

18 Quando schedulare? (Dove inserisce il programmatore le invocazioni allo scheduler?) 1.Un processo si blocca in attesa di un evento. 2.Un processo termina l'esecuzione. Altrimenti, il processore rimane inattivo. 18

19 Prelazione (Ovvero il kernel strappa con la forza la CPU ad un processo) Prelazione: è l'atto di interrompere momentaneamente un processo troppo avido di CPU a favore di un altro che sta aspettando l'esecuzione. Lo schema precedentemente visto non ha prelazione. Un processo CPU-bound può provocare starvation di altri processi. Nessuna garanzia sull'interattività (i tempi di risposta possono essere molto alti). 19

20 Scheduling con prelazione (Ovvero il kernel strappa con la forza la CPU ad un processo) Interviene nei seguenti casi. 1.Un processo si blocca in attesa di un evento. 2.Un processo termina l'esecuzione. 3.È stato creato un nuovo processo. 4.Un processo è interrotto da una interruzione (inclusa la scadenza del quanto di tempo). 5.Un processo passa dallo stato bloccato allo stato pronto. 20

21 Scheduling in Linux (La funzione schedule()) In Linux, lo scheduler dei processi è con prelazione. Esso è implementato dalla funzione schedule(), definita nel file: $LINUX/kernel/sched/core.c. Sceglie la task_struct di un nuovo processo. Salva lo stato del processo attuale nella sua task_struct. Ripristina nei registri lo stato del nuovo processo. Salta alla prossima istruzione utile del nuovo processo. 21

22 Punti di invocazione di schedule() (La funzione schedule()) La funzione schedule() è invocata nelle seguenti occasioni. Blocco dovuto ad I/O. Blocco dovuto ad evento di sincronizzazione. Al termine di una chiamata di sistema. Al termine di un gestore delle interruzioni. 22

23 Il flag di rischedulazione (Non è necessario rischedulare sempre) Lo scheduler non rischedula per forza, bensì solamente se forzato dagli eventi (ad esempio, un processo a priorità più elevata è pronto). In caso contrario, viene favorito il processo precedentemente in esecuzione. Il kernel usa un flag (TIF_NEED_RESCHED) della task_struct del processo in esecuzione per segnalare la necessità di rischedulare. 23

24 Schedulazione condizionata (Non è necessario rischedulare sempre) Il kernel controlla se è il flag è impostato mediante la funzione need_resched(), definita nel file seguente: $LINUX/include/linux/sched.h. Se tale funzione ritorna 1 (TRUE) allora viene invocata la schedule(), altrimenti no. 24

25 Funzioni rientranti (Un altro problema) Dati di fatto. Le macchine moderne sono multiprocessore. I SO moderni sono multiutente e time sharing. Le operazioni di I/O sono gestite in maniera asincrona tramite DMA e interruzioni. Conseguenza inevitabile. Funzione rientrante: una funzione del kernel può essere invocata di nuovo prima del termine di una sua precedente invocazione. 25

26 Rientranza di schedule() (L'esempio più lampante) In questo istante, la funzione schedule() non è ancora terminata. La sostituzione dei processi provoca un salto diretto al processo B. Processo A sys_read() Processo B User Kernel I/O DMA schedule() Schedulatore dei processi 26

27 Rientranza di schedule() (L'esempio più lampante) All'arrivo della richiesta di interruzioni da parte del disco, parte il gestore delle interruzioni. Al termine della sua esecuzione, lo schedulatore dei processi rischedula, nel caso, il processo A. Processo B Gestore interruzioni need_resched() schedule() Schedulatore dei processi Processo A User Kernel IRQ 27

28 Rientranza di schedule() (L'esempio più lampante) Notate come schedule() sia stata nuovamente invocata prima che la precedente istanza di schedule() sia terminata. Processo B Gestore interruzioni need_resched() schedule() Schedulatore dei processi Processo A User Kernel IRQ 28

29 Rientranza di schedule() (L'esempio più lampante) Al termine della schedule(), il controllo è ritornato alle funzioni invocate dalla chiamata di sistema sys_read(). Processo A schedule() Schedulatore dei processi sys_read() Virtual File System Processo A User Kernel 29

30 Vantaggi della rientranza (A che serve avere una schedule() invocabile in maniera concorrente?) Il kernel esegue in maniera più efficiente su architetture SMP. Esecuzione concorrente di funzioni critiche. 30

31 Svantaggi della rientranza (Cosa si paga per avere schedule() rientrante?) Le funzioni devono essere progettate in modo tale da essere eseguibili concorrentemente. L'accesso a variabili globali va evitato come la peste, se possibile. Se proprio non si riesce ad evitare l'accesso a variabili globali, tale accesso deve essere serializzato. Una funzione che non rispetta tali vincoli è detta non rientrante. La sua esecuzione su più CPU va impedita per evitare corruzione sui dati. Limite forte alla scalabilità del kernel. 31

32 Idle task (Che succede se sono tutti bloccati) Se nessun processo è in grado di eseguire, il kernel esegue un processo speciale detto swapper o idle task. PID = 0. Mette a riposo il processore e aspetta una interruzione. 32

33 CAMBIO DI CONTESTO 33

34 Cambio di contesto (Come si salta di palo in frasca) L'operazione di scambio dei due processi prende il nome di cambio di contesto (context switch). Contesto = contenuto del PCB. Operazioni svolte: Salvataggio del contesto del processo attuale. Ripristino del contesto del nuovo processo. Durata di un cambio di contesto: 1μsec 1msec (dipende fortemente dall'architettura hardware). 34

35 Come avviene il salto al nuovo processo (Hop!) Uno dei campi contenuti nel contesto è il registro Instruction Pointer. Se tale registro fosse ripristinato per ultimo, la CPU salterebbe automaticamente alla prossima istruzione della nuova traccia. Nella sostanza, il salto avviene proprio così. 35

36 Come avviene il salto al nuovo processo (Houston, we've had a problem) Problema: un processo appena creato (fork()) deve essere inizializzato prima di poter eseguire la prima volta. Non si può eseguire la sua traccia direttamente modificando l'instruction Pointer. Si vorrebbe invocare una funzione inizializzatrice prima. 36

37 Come avviene il salto alla nuova traccia (It gets technical now) Si usa un piccolo trucco. Si spinge sullo stack l'indirizzo della prossima istruzione da eseguire (funzione inizializzatrice o prossima istruzione della traccia). Si salta ad una funzione in cui vengono effettuati gli ultimi preparativi. Si salta (JMP), non si invoca (CALL); in tal modo non si tocca lo stack. La funzione invocata esegue un return (RET). L'Instruction Pointer è caricato con l'ultimo valore presente sullo stack (l'indirizzo desiderato). 37

38 La macro switch_to() (Argh!) La macro switch_to(), definita nel file: $LINUX/arch/x86/include/asm/switch_to.h implementa questa variante. La funzione inizializzatrice è la seguente: ret_from_fork(). 38