Su un kernel preventivo, un processo in esecuzione in modalità kernel può essere sostituito da un altro processo mentre si trova nel mezzo di una funzione del kernel.
Questo si applica solo ai processi in esecuzione in modalità kernel, una CPU che esegue processi in modalità utente è considerata "inattiva". Se un processo in modalità utente desidera richiedere un servizio al kernel, deve emettere un'eccezione che il kernel può gestire.
Ad esempio:
Processo A esegue un gestore di eccezioni, Process B viene risvegliato da una richiesta IRQ, il kernel sostituisce il processo A con B (un cambio di processo forzato). Processo A rimane incompiuto. Lo scheduler decide in seguito se processare A ottiene il tempo della CPU o meno.
Su un kernel non preemptive, elabora A avrebbe semplicemente utilizzato tutto il tempo del processore fino a quando non ha finito o decide volontariamente di consentire ad altri processi di interromperlo (un cambio di processo pianificato).
Gli odierni sistemi operativi basati su Linux in genere non includono un kernel completamente preventivo, ci sono ancora funzioni critiche che devono essere eseguite senza interruzioni. Quindi penso che potresti chiamarlo un "kernel preventivo selettivo".
A parte questo, ci sono approcci per rendere il kernel Linux (quasi) completamente preemptive.
- Wiki di Linux in tempo reale
- Articolo LWN
la prelazione è -> La capacità del sistema operativo di anticipare o interrompere un'attività attualmente pianificata a favore di un'attività con priorità più alta. La pianificazione può essere una, ma non limitata a, pianificazione di processi o I/O ecc.
Sotto Linux, i programmi in spazio utente sono sempre stati prerilasciabili:il kernel interrompe i programmi in spazio utente per passare ad altri thread, utilizzando il normale tick dell'orologio. Quindi, il kernel non aspetta che i programmi in spazio utente rilascino esplicitamente il processore (che è il caso del multitasking cooperativo). Ciò significa che un ciclo infinito in un programma in spazio utente non può bloccare il sistema.
Tuttavia, fino ai kernel 2.6, il kernel stesso non era preemptible:non appena un thread entrava nel kernel, non poteva essere preemptible per l'esecuzione di un altro thread. Quindi, la prelazione del kernel è stata introdotta nei kernel 2.6, e si può abilitarla o disabilitarla usando l'opzione CONFIG_PREEMPT. Se CONFIG_PREEMPT è abilitato, allora il codice kernel può essere anticipato ovunque, tranne quando il codice ha disabilitato gli interrupt locali. Un loop infinito nel codice non può più bloccare l'intero sistema. Se CONFIG_PREEMPT è disabilitato, viene ripristinato il comportamento 2.4.
Ricitato e formattato da:http://www.linuxquestions.org/questions/linux-general-1/pre-emptive-vs-non-pre-emptive-kernel-582437/