C'era una volta (80386 era) la maggior parte dei computer aveva meno di 16 MiB di RAM, non c'erano dispositivi PCI mappati in memoria, e 1 GiB di spazio suonava incredibilmente enorme (specialmente per un "kernel temporaneo" che era previsto solo per essere usato fino a quando GNU ha terminato il proprio kernel). Mappare tutta la RAM fisica nello spazio del kernel sembrava una buona idea; quindi è quello che è successo.
Il tempo è passato. Un sacco di codice (driver di dispositivo, ecc.) È stato scritto che si basava su "tutta la RAM fisica mappata nello spazio del kernel".
Più tempo è passato. Il PCI è arrivato Computer con > 1 GiB di RAM è arrivato. Intel ha aggiunto PAE in modo che i computer potessero avere quasi 64 GB di RAM. Lo spazio del kernel era ancora limitato a 1 GiB. L'idea di "tutta la memoria fisica mappata nello spazio del kernel" si è rotta molto. Però; a questo punto un sacco di codice si basava su "tutta la RAM fisica mappata nello spazio del kernel". Era troppo tardi per correggere la causa principale del problema e fare correttamente la gestione della memoria (vedi nota alla fine).
Questo ha portato a brutti hack / work-arounds; iniziando con "2 GiB / 2 GiB split", che non era un cattivo compromesso per i sistemi con circa 1 GiB di RAM (e non ha aiutato quando ci sono 2 GiB di RAM o più).
Il "4 GiB / 4 GiB" è stato il prossimo scemo. Il problema qui è che il passaggio da uno spazio di indirizzi virtuali a un altro è estremamente costoso (a causa del flushing TLB e dei mancati TLB); e per ottenere "4 GiB / 4 GiB" ciò doveva accadere ogni volta che la CPU passava da "spazio utente" a "spazio kernel" (ogni chiamata API kernel, ogni IRQ, ecc.) e ogni volta che la CPU si riavviava (da " kernel space "back to" user space ").
La "mappatura di memoria alta" è il terzo tentativo di non correggere la vera causa del problema.
Più tempo è passato. Alla fine, AMD ha introdotto la modalità lunga e il kernel poteva contenere fino a 128 TiB di spazio. Lo sviluppatore di Linux ha gioito - 128 TiB di spazio sembra enormemente enorme oggi (quando i computer in genere hanno meno di 128 GB di RAM), proprio come 1 GB di spazio sembrava enormemente enorme quasi 30 anni fa. Questo risolve il problema "per sempre", giusto?!
Per dispositivi DMA che possono utilizzare solo la RAM nei primi 4 GiB dello spazio dell'indirizzo fisico; per lo schema "4 GiB / 4 GiB" possono trasferire i dati nello / dallo spazio del kernel abbastanza facilmente. Tuttavia, quasi tutti questi dati devono essere trasferiti allo / dallo spazio utente; il che significa che hai ancora bisogno di buffer di rimbalzo e lo schema "4 GiB / 4 GiB" non aiuta molto.
IOMMU avrebbe potuto aiutare a evitare i buffer di rimbalzo, ma prima che esistesse la modalità lunga la maggior parte dei computer non disponeva di IOMMU. Anche ora Intel non lo fornisce su tutte le sue CPU (nel tentativo di far pagare extra alle persone che non hanno funzionalità disabilitate). Ciò significa che affinché il kernel funzioni correttamente su tutti i computer, deve funzionare correttamente solo con i computer senza IOMMU.
Nota: In realtà, l'approccio "tutta la RAM fisica mappata nello spazio del kernel" ha davvero un piccolo vantaggio, perché un kernel non ha assolutamente bisogno di accedere alla stragrande maggioranza della RAM. Tuttavia questo approccio sembra facile per i principianti che non capiscono correttamente il paging (e non capiscono come sia possibile utilizzare il "paging potente" per avvantaggiare il kernel proprio come sono usati per i processi). Per questo motivo, "tutta la RAM fisica mappata nello spazio del kernel" è un errore di progettazione ricorrente tra gli sviluppatori di kernel / OS appassionati. Ti preghiamo di comprendere che Linus era uno sviluppatore di kernel hobbista quando questo errore è stato fatto (ed è molto facile ignorarlo ora quando vedi Linux moderno).