Ci sono due casi in cui il codice di pianificazione schedule() è invoked-In quale contesto viene eseguito il codice dello scheduler?
Quando un processo chiama volontariamente schedule()
Timer interrupt chiama schedule()
Nel caso 2, penso schedule() funziona nel contesto di interruzione, ma per quanto riguarda il primo caso? Esegue nel contesto del processo che lo ha invocato?
Esistono altri scenari che richiamano schedule()?
schedule() viene sempre eseguito nel contesto del processo. Nel secondo caso, quando viene avviato da un interrupt del timer, si trova nel percorso di ritorno dal kernel al processo interrotto in cui viene chiamato schedule().
Well schedule() si verifica come una chiamata di sistema che è solo un interrupt trap AFAIK giusto? –
@Jesus Ramos: "contesto di processo" e "contesto di interruzione" sono termini di sviluppo del kernel di Linux che descrivono il contesto del codice che si sta eseguendo nello spazio del kernel: se può essere considerato come eseguibile per conto di un particolare processo (come in un sistema chiamata) o manutenzione alterativa di un interrupt hardware. – caf
Sì, conosco la terminologia, il fatto è che è stato un po 'confuso in questo senso perché una chiamata di sistema è tecnicamente un'interruzione, quindi non sono sicuro se questo è ciò che intendeva o il modo in cui la chiamata viene effettivamente eseguita. –
Quando un processo chiama schedule(), viene eseguito in un contesto di chiamata di sistema basato su interrupt. Nel secondo caso un interrupt hardware attiva la chiamata schedule(). In entrambi i casi funziona come un'interruzione. AFAIK sono le uniche volte in cui viene chiamato schedule() perché la maggior parte della manipolazione della pianificazione implica la modifica della coda di esecuzione del kernel delle cose da pianificare anche se un processo può essere interrotto, ma di solito viene fatto tramite un interrupt per indicare al processo di produrre o il processo che produce si.
__schedule() è la funzione di pianificazione principale.
I principali mezzi di guida dello scheduler e inserendo questa funzione quindi sono:
blocco esplicito: mutex, semafori, waitqueue, ecc
TIF_NEED_RESCHED bandiera è selezionata interrupt e ritorno userspace percorsi. Ad esempio, consultare arch/x86/entry_64.S. Per guidare la prelazione tra le attività, lo schedulatore imposta il flag nel gestore di interrupt del timer scheduler_tick().
I risvegli non causano realmente l'ingresso nella pianificazione(). Aggiungono un'attività alla coda di esecuzione e il gioco è fatto. Ora, se la nuova attività aggiunta alla vigilia della coda preempts l'attività corrente, quindi i set wakeup TIF_NEED_RESCHED e il calendario() viene chiamato sulla vicina occasione possibile:
http://lxr.free-electrons.com/source/kernel/sched/core.c#L2389
C'è un altro caso in cui verrà richiamato() orario: quando un blocchi di processo (per esempio a causa di un'operazione di I/O). – omer
@omer È il timer che interrompe la pianificazione della chiamata() quando il processo si blocca. quindi il tuo caso è lo stesso del caso 2 – baotiao