Di tutti i computer che abbia mai posseduto o utilizzato, quello che si è avviato più velocemente è stato degli anni '80; quando la tua mano è passata dall'interruttore di alimentazione alla tastiera, l'interprete BASIC era pronto per i tuoi comandi. I computer moderni impiegano da 15 secondi per un laptop a minuti per l'avvio di un piccolo server domestico. Perché c'è una tale differenza nei tempi di avvio?
Un microcomputer degli anni '80 che si avviava direttamente su un prompt BASIC aveva una CPU molto semplice che iniziava a recuperare ed eseguire istruzioni da un indirizzo di memoria immediatamente dopo aver ricevuto l'alimentazione. Poiché questi sistemi avevano BASIC nella ROM, non c'era tempo di caricamento:si arrivava al prompt BASIC molto rapidamente. I sistemi più complessi della stessa epoca, come il PC IBM o il Macintosh, impiegavano molto tempo per l'avvio (~30 secondi), sebbene ciò fosse dovuto principalmente alla necessità di leggere il sistema operativo (OS) da un floppy disk. Sono stati trascorsi solo una manciata di secondi nel firmware prima di poter caricare un sistema operativo.
I server moderni in genere trascorrono minuti, anziché secondi, nel firmware prima di arrivare al punto di avviare un sistema operativo dal disco. Ciò è in gran parte dovuto alla maggiore complessità dei sistemi moderni. Non è più possibile che una CPU si avvii e inizi a eseguire le istruzioni a piena velocità; ci siamo abituati al ridimensionamento della frequenza della CPU, agli stati di inattività che consentono di risparmiare molta energia e a più core della CPU. In effetti, all'interno delle moderne CPU c'è un numero sorprendente di CPU più semplici che aiutano ad avviare i core principali della CPU e forniscono servizi di runtime come la limitazione della frequenza quando fa troppo caldo. Nella maggior parte delle architetture CPU, il codice in esecuzione su questi core all'interno della CPU viene fornito come BLOB binari opachi.
Sui sistemi OpenPOWER, ogni istruzione eseguita su ogni core all'interno della CPU è un software open source. Su macchine con OpenBMC (come il sistema AC922 di IBM e i sistemi TALOS II e Blackbird di Raptor), questo si estende anche al codice in esecuzione sul Baseboard Management Controller. Ciò significa che possiamo ottenere un'enorme quantità di informazioni su ciò che impiega così tanto tempo dal momento in cui colleghi un cavo di alimentazione al momento in cui viene visualizzata una richiesta di accesso familiare.
Se fai parte di un team che lavora sul kernel Linux, probabilmente avvii molti kernel. Se fai parte di un team che lavora sul firmware, probabilmente avvierai molte immagini firmware diverse, seguite da un sistema operativo per assicurarti che il firmware funzioni ancora. Se riusciamo a ridurre il tempo di avvio dell'hardware, questi team possono diventare più produttivi e gli utenti finali potrebbero essere grati quando configurano i sistemi o si riavviano per installare gli aggiornamenti del firmware o del sistema operativo.
Programmazione e sviluppo
- Blog degli sviluppatori Red Hat
- Programmazione cheat sheet
- Prova gratuitamente:Red Hat Learning Subscription
- eBook:un'introduzione alla programmazione con Bash
- Cheat sheet per gli script di Bash Shell
- eBook:modernizzare Enterprise Java
Nel corso degli anni, sono stati apportati molti miglioramenti al tempo di avvio delle distribuzioni Linux. I moderni sistemi init gestiscono bene le operazioni contemporaneamente e su richiesta. Su un sistema moderno, una volta avviata l'esecuzione del kernel, possono essere necessari pochissimi secondi per arrivare a una richiesta di accesso. Questa manciata di secondi non è il posto giusto per ottimizzare il tempo di avvio; dobbiamo andare prima:prima di arrivare al sistema operativo.
Sui sistemi OpenPOWER, il firmware carica un sistema operativo avviando un kernel Linux memorizzato nel chip flash del firmware che esegue un programma userspace chiamato Petitboot per trovare il disco che contiene il sistema operativo che l'utente desidera avviare e kexec() su di esso. Questo riutilizzo del codice sfrutta gli sforzi compiuti per rendere più rapido l'avvio di Linux. Anche così, abbiamo trovato posti nella nostra configurazione del kernel e nello spazio utente in cui potevamo migliorare e ridurre facilmente i secondi del tempo di avvio. Con queste ottimizzazioni, l'avvio dell'ambiente Petitboot è una percentuale a una cifra del tempo di avvio, quindi abbiamo dovuto trovare ulteriori miglioramenti altrove.
Prima dell'avvio dell'ambiente Petitboot, c'è un precedente bit di firmware chiamato Skiboot, e prima c'è Hostboot. Prima di Hostboot c'è il Self-Boot Engine, un core separato sul die che ottiene un singolo core della CPU ed esegue le istruzioni dalla cache di livello 3. Questi componenti sono i punti in cui possiamo ottenere il massimo nella riduzione del tempo di avvio, poiché ne occupano la stragrande maggioranza. Forse alcuni di questi componenti non sono ottimizzati a sufficienza o fanno tutto il possibile in parallelo?
Un'altra via di attacco è il tempo di riavvio piuttosto che il tempo di avvio. Al riavvio, lo facciamo davvero è necessario reinizializzare tutti l'hardware?
Come qualsiasi sistema moderno, le soluzioni per migliorare il tempo di avvio (e riavvio) sono state un misto di fare di più in parallelo, affrontare l'eredità e (probabilmente) barare.
Stewart Smith presenterà Booting Fast su linux.conf.au, dal 21 al 25 gennaio a Christchurch, in Nuova Zelanda.