Risposte:
Su un kernel preventivo, un processo in esecuzione in modalità kernel può essere sostituito da un altro processo nel mezzo di una funzione del kernel.
Questo vale solo per i processi in esecuzione in modalità kernel, una CPU che esegue i processi in modalità utente è considerata "inattiva". Se un processo in modalità utente vuole richiedere un servizio al kernel, deve emettere un'eccezione che il kernel può gestire.
Come esempio:
Il processo Aesegue un gestore eccezioni, il processo Bviene risvegliato da una richiesta IRQ, il kernel sostituisce il processo Acon B(un interruttore di processo forzato). Il processo Arimane incompiuto. Lo scheduler decide in seguito se il processo Aottiene o meno il tempo della CPU.
Su un kernel non preventivo, il processo Aavrebbe semplicemente usato tutto il tempo del processore fino al termine o alla decisione volontaria di consentire ad altri processi di interromperlo (un interruttore di processo pianificato).
Oggi i sistemi operativi basati su Linux generalmente non includono un kernel completamente preventivo, ci sono ancora funzioni critiche che devono essere eseguite senza interruzione. Quindi penso che potresti chiamarlo un "kernel preventivo selettivo".
A parte questo, ci sono approcci per rendere il kernel Linux (quasi) completamente preventivo.
la prelazione è -> La capacità del sistema operativo di anticipare o interrompere un'attività attualmente pianificata a favore di un'attività con priorità più elevata. La pianificazione può essere una, ma non solo, una programmazione di processo o I / O ecc.
Sotto Linux, i programmi di spazio utente sono sempre stati preimpostabili: il kernel interrompe i programmi di spazio utente per passare ad altri thread, usando il normale tick di clock. Quindi, il kernel non attende che i programmi dello spazio utente rilascino esplicitamente il processore (come nel caso del multitasking cooperativo). Ciò significa che un ciclo infinito in un programma spazio utente non può bloccare il sistema.
Tuttavia, fino ai kernel 2.6, il kernel stesso non era preemettibile: non appena un thread è entrato nel kernel, non è stato possibile impedire l'esecuzione di un altro thread. Tuttavia, questa assenza di preemption nel kernel ha causato diversi problemi in termini di latenza e scalabilità. Quindi, la preemption del kernel è stata introdotta nei kernel 2.6 e si può abilitarla o disabilitarla usando l'opzione CONFIG_PREEMPT. Se CONFIG_PREEMPT è abilitato, è possibile preemptare il codice del kernel ovunque, tranne quando il codice ha disabilitato gli interrupt locali. Un ciclo infinito nel codice non può più bloccare l'intero sistema. Se CONFIG_PREEMPT è disabilitato, viene ripristinato il comportamento 2.4.
Sottotitolato e formattato da: http://www.linuxquestions.org/questions/linux-general-1/pre-emptive-vs-non-pre-emptive-kernel-582437/
Un kernel preventivo consente di preimpostare un processo mentre è in esecuzione in modalità kernel. Un kernel non preventivo non consente di impedire un processo in esecuzione in modalità kernel; un processo in modalità kernel verrà eseguito fino a quando non esce dalla modalità kernel, si blocca o cede volontariamente il controllo della CPU. Ovviamente, un kernel non preventivo è essenzialmente privo di condizioni di competizione sulle strutture di dati del kernel, poiché nel kernel è attivo solo un processo alla volta. Non possiamo dire lo stesso dei kernel preventivi, quindi devono essere attentamente progettati per garantire che i dati del kernel condivisi siano liberi da condizioni di razza. I kernel preventivi sono particolarmente difficili da progettare per le architetture SMP, poiché in questi ambienti è possibile eseguire simultaneamente due processi in modalità kernel su processori diversi. Un kernel preventivo è più adatto per la programmazione in tempo reale, poiché consentirà a un processo in tempo reale di anticipare un processo attualmente in esecuzione nel kernel. Inoltre, un kernel preventivo può essere più reattivo, poiché esiste un rischio minore che un processo in modalità kernel venga eseguito per un periodo arbitrariamente lungo prima di affidare il processore ai processi in attesa. Naturalmente, questo effetto può essere minimizzato progettando il codice del kernel che non si comporta in questo modo. Più avanti in questo capitolo, esploreremo come vari sistemi operativi gestiscono la preemption all'interno del kernel. questo effetto può essere minimizzato progettando il codice del kernel che non si comporta in questo modo. Più avanti in questo capitolo, esploreremo come vari sistemi operativi gestiscono la preemption all'interno del kernel. questo effetto può essere minimizzato progettando il codice del kernel che non si comporta in questo modo. Più avanti in questo capitolo, esploreremo come vari sistemi operativi gestiscono la preemption all'interno del kernel.