Perché i primi sviluppatori Linux hanno scelto di implementare un kernel non preventivo? Salvare la sincronizzazione?
Per quanto ne so, Linux è stato sviluppato all'inizio degli anni '90, quando i PC avevano un singolo processore. Quale vantaggio offre un kernel non preventivo in tali PC? Perché, tuttavia, il vantaggio è ridotto dai processori multi-core?
Risposte:
Nel contesto del kernel Linux, quando le persone parlano di prelazione si riferiscono spesso alla capacità del kernel di interrompere se stesso - essenzialmente, cambiare attività durante l'esecuzione del codice del kernel. Consentire che ciò accada è piuttosto complesso, che è probabilmente la ragione principale per cui il kernel è diventato molto tempo pre-empable.
All'inizio la maggior parte del codice del kernel non poteva essere interrotta comunque, poiché era protetta dal blocco del kernel grande. Quel blocco è stato progressivamente eliminato da un numero sempre maggiore di codice del kernel, consentendo in parallelo più chiamate simultanee al kernel (che è diventato più importante man mano che i sistemi SMP sono diventati più comuni). Ma ciò non ha reso il kernel stesso pre-eseguibile; ciò ha richiesto ancora più sviluppo, culminando nel PREEMPT_RTset di patch che alla fine è stato unito nel kernel mainline (ed è stato in grado di anticipare comunque il BKL). Al giorno d'oggi il kernel può essere configurato per essere più o meno pre-eseguibile, a seconda della velocità effettiva e delle caratteristiche di latenza che stai cercando; vedere la relativa configurazione del kernel per i dettagli.
Come puoi vedere dalle spiegazioni nella configurazione del kernel, la prelazione influisce sulla velocità effettiva e sulla latenza, non sulla concorrenza. Sui sistemi a CPU singola, la prelazione è ancora utile perché consente agli eventi di essere elaborati con tempi di reazione più brevi; tuttavia, si traduce anche in un throughput inferiore (poiché il kernel impiega tempo a cambiare task). La prelazione consente a una determinata CPU, in un sistema a CPU singola o multipla, di passare a un'altra attività più rapidamente. Il fattore limitante sui sistemi a più CPU non è la prelazione, è i blocchi, grandi o meno: ogni volta che un codice temporale prende un blocco, significa che un'altra CPU non può iniziare a eseguire la stessa azione.
Il kernel preventivo significa solo che non esiste un Big Kernel Lock .
Linux aveva un multi-tasking preventivo (cioè il codice utente era pre-eseguibile) sin dal suo primo momento (per quanto ne so, il primissimo Linux 0.0.1 caricato da Linus sul server ftp funet era già multitasking preventivo). Se ad esempio sono stati eseguiti più processi di compressione o compilazione, sono stati eseguiti in parallelo dal primo momento.
Contrariamente al - all'epoca - Win31 ampiamente usato. Su Win31, se un'attività ha ottenuto la CPU dal "kernel", per impostazione predefinita era sua responsabilità determinare quando restituire il controllo al sistema operativo (o ad altre attività). Se un processo non aveva un supporto speciale per questa funzione (che richiedeva un lavoro di programmazione aggiuntivo), durante l'esecuzione, tutte le altre attività venivano sospese. Anche la maggior parte delle app di base integrate in Win31 ha funzionato così.
Multitasking preventivo significa che le attività non hanno modo di allocare la CPU come vogliono. Invece, se il loro intervallo di tempo scade, il kernel toglie loro la CPU. Pertanto, nei sistemi operativi preventivi, un processo scritto in modo errato o mal funzionante non può bloccare il sistema operativo o evitare l'esecuzione di altri processi. Linux è sempre stato preventivo per i processi dello spazio utente.
Il Big Kernel Lock significa che in alcuni casi, all'interno dello spazio del kernel , potrebbero esserci ancora alcuni blocchi, impedendo ad altri processi di eseguire il codice protetto. Ad esempio, non è possibile montare più filesystem contemporaneamente: se si impartiscono più comandi di mount, questi vengono comunque eseguiti consecutivamente, poiché il montaggio di elementi necessari per allocare il Big Kernel Lock.
Rendere preventivo il kernel aveva richiesto l'eliminazione di questo grosso blocco del kernel, ovvero fare in modo che il mount e qualsiasi altra attività potessero essere eseguiti contemporaneamente. È stato un grande lavoro.
Storicamente, ciò è stato reso davvero urgente dal crescente supporto di SMP (supporto multi-CPU). Per la prima volta, c'erano davvero schede madri con più CPU. Successivamente più CPU ("core") sono state integrate in un singolo chip, oggi le schede madri con più CPU sono già rare (in genere si trovano in costosi sistemi server). Anche i sistemi veramente single-core (dove esiste solo una CPU, con un singolo core) sono rari.
Pertanto, la risposta alla tua domanda non è quella "qual è stata la ragione della non preventività", perché è sempre stata preventiva. La vera domanda è: cosa ha reso davvero necessaria l'esecuzione preventiva del kernel . La risposta è per questo: il rapporto crescente tra molti sistemi CPU e molti core.
Questa non è una risposta tecnica ma una risposta storica alla domanda specifica posta dall'OP: "Qual è stato il motivo della non preventività dei kernel Linux più vecchi?"
(Suppongo, come spiegato da @peterh nella sua risposta e nei suoi commenti, che per "non-prevenzione" l'OP si riferisce a uno o entrambi del fatto che un solo processo utente potrebbe essere all'interno del kernel (in un'API) in un ora e / o Big Kernel Lock.)
Linus Torvalds era interessato a sapere come funzionavano i sistemi operativi e il modo in cui imparava era di scriverne uno. Il suo modello, base e ambiente di sviluppo iniziale era Minix, un sistema operativo esistente a scopi didattici (ovvero non un sistema operativo di produzione) che non era gratuito (come in open source, a quel tempo - non era gratuito come nella birra, o).
Quindi ha scritto un kernel senza alcuna prelazione (il Big Kernel Lock menzionato in altre risposte) perché è il modo in cui lo fai se vuoi che il tuo nuovo sistema operativo sia avviato e funzionante rapidamente per scopi educativi: è molto molto più semplice in quel modo. Un kernel per supportare la multiprogrammazione simultanea di programmi e dispositivi utente è abbastanza difficile - è estremamente difficile rendere simultaneo il kernel stesso.
Se avesse saputo quanto sarebbe diventato popolare / utile / importante Linux ... probabilmente lo avrebbe fatto allo stesso modo. (Solo IMO, non ho idea di cosa pensi realmente.) Perché devi camminare prima di poter correre.
E rimase così a lungo perché a) c'era molto altro lavoro da fare per rendere Linux quello che è oggi (o anche quello che era allora) eb) cambiarlo sarebbe una grande impresa difficile (come spiegato in altre risposte).