sreadahead e boot in 5 secondi

[flx2000]

Si sente molto parlare dei famosi 5 secondi per il boot completo di un netbook, ma a quanto sembra nessuno qui riesce a ottenere risultati così spinti.
Attualmente mi sono "piantato" sui 14 secondi incluso X, ma non ho ancora utilizzato l'opzione sreadahead per il caricamento asincrono dei file di boot.

In questo momento sto compilando il nuovo kernel 2.6.29-rc5.
L'ho patchato senza problemi con il file previsto per sreadahead-1.0, ho compilato l'eseguibile sreadahead e ora ho un po' di dubbi sul da farsi.

Pensavo di eseguire /sbin/sreadahead all'invio del sistema, ma non mi è chiaro perché dovrebbe essere più veloce, e dove andrà a scrivere il file package con l'elenco dei file da precaricare, né c'è scritto come fare per crearlo.

Qualcuno ha voglia di approcciare questo problema e trovare una soluzione cooperando?
Grazie

[lele85]

Sul forum di archlinux abbiamo provato a fare qualcosa in questo senso ma per ottenere tempi di quei livelli servono:

1) Hard disk SSD
2) Rivoluzionare gli script di avvio per parallelizzarli il più possibile
3) Sbudellare Xorg

Detto questo visto che impiego un 18 secondi ad avviare la distro con parecchi servizi non mi lamento e aspetto che i risultati della ricerca degli ingegneri intel vengano portati upstream. Purtroppo l'installazione che uso è quella su cui studio e lavoro quindi non posso permettere di perdere tempo in eventuali reinstallazioni da smanettamento forsennato ;-)

[flx2000]

Attualmente sono riuscito ad ottenere 13 secondi di boot compreso l'ambiente grafico, ma vorrei scendere di almeno altri 5 secondi, quando ho tempo da dedicare alla cosa.

In questo momento, infatti, non ho ancora ottimizzato X, che di default impiega 7 secondi per avviarsi.

Per la cronaca, allego il bootchart del mio avvio.

Il mio PC è quello su cui lavoro, ed essendo portatile preferisco spegnerlo appena non mi serve.
Avere un boot time di 13 secondi è già qualcosa (contro gli oltre 30 che ci volevano prima che iniziassi a smanettarci un po').

[flx2000]

Parallelizzando i servizi in rc5.d (quelli caricati al boot quando si entra in modalità grafica) ho recuperato altri 2 secondi, passando così a 11 secondi per il boot completo in modalità grafica.



PS: Cerco sempre persone che hanno voglia di collaborare alla realizzazione di script di boot ottimizzati.

[eclissi83]

a parte la cosa interessante dello smanettamento per puro scopo di divertimento/conoscenza, non e' piu' comodo far funzionare correttamente lo stand-by/sospensione? personalmente uso un iBook G4 (per motivi di lavoro con Mac OS X) e non lo spengo quasi mai, lo trovo molto piu' comodo cosi'...

ciao

[Fil9998]

uso distro standard ceh arrivano al DE in 45 secondi ...

onestamente arrivarci in 30 secondi in meno potrebbe esser carino, ma in fin dei conti semi-useless specie se per arrivarci bisogna perderci mezze iornate di configurazione.

bhà...

[flx2000]

Originariamente inviato da eclissi83

a parte la cosa interessante dello smanettamento per puro scopo di divertimento/conoscenza, non e' piu' comodo far funzionare correttamente lo stand-by/sospensione? personalmente uso un iBook G4 (per motivi di lavoro con Mac OS X) e non lo spengo quasi mai, lo trovo molto piu' comodo cosi'...

ciao

Chiaramente, lo scopo è quello di imparare a gestire manualmente la configurazione dei processi più delicati di un sistema Linux.
Che poi dia risultati pratici è sicuramente tutto di guadagnato!

La sospensione utilizza comunque la batteria, quindi è inutile se il portatile non può essere ricaricato fino al giorno dopo. Per questo è stata scartata di base.

L'ibernazione sarebbe una strada alternativa, ma riservare 2Gb di spazio per l'ibernazione su un netbook con disco da 8Gb che scrive a 6Mb/s è controproducente.

[flx2000]

Originariamente inviato da Fil9998

uso distro standard ceh arrivano al DE in 45 secondi ...

onestamente arrivarci in 30 secondi in meno potrebbe esser carino, ma in fin dei conti semi-useless specie se per arrivarci bisogna perderci mezze iornate di configurazione.

bhà...

Lo scopo di questo progetto è quello di definire un metodo di ottimizzazione dei sistemi Linux.

Già solo questo vuol dire che si vuole fare a meno delle distribuzioni. Esse hanno infatti la necessità di essere più generiche possibili, e quindi nascono per scopi diametralmente opposti a quello di cui stiamo parlando qui.

Se non ti serve un sistema ottimizzato è logico che scegli una distro già bella e pronta!

[Cobra78]

Originariamente inviato da flx2000

Chiaramente, lo scopo è quello di imparare a gestire manualmente la configurazione dei processi più delicati di un sistema Linux.
Che poi dia risultati pratici è sicuramente tutto di guadagnato!

La sospensione utilizza comunque la batteria, quindi è inutile se il portatile non può essere ricaricato fino al giorno dopo. Per questo è stata scartata di base.

L'ibernazione sarebbe una strada alternativa, ma riservare 2Gb di spazio per l'ibernazione su un netbook con disco da 8Gb che scrive a 6Mb/s è controproducente.

Veramente un portatile con una buona batteria dura dei giorni in sospensione, e anzi per pause di lavoro relativamente brevi (sicuro attorno alla mezz'ora) si consuma meno batteria a sospenderlo che a spegnerlo e riaccenderlo.

[ozeta]

ma che distribuzione usi?

comunque ho notato dei processi che iniziano per k.

secondo me devi passare a qualcosa di più leggero. non dico una openbox ma un lxde o un xfce

[flx2000]

Originariamente inviato da ozeta

ma che distribuzione usi?

comunque ho notato dei processi che iniziano per k.

secondo me devi passare a qualcosa di più leggero. non dico una openbox ma un lxde o un xfce

Nessuna distribuzione, ho compilato ogni singolo programma da zero.
I processi che vedi con la K sono relativi al kernel e sono parte del sistema operativo.
Nello specifico "kthreadd" è il demone dei thread del kernel, mente "klogd" è il demone del log del kernel.

Come desktop environment c'è XFCE, e Slim è l'interfaccia per il login grafico.

[ozeta]

puoi eliminare slim facendo partire direttamente xorg, questo dovrebbe farti recuperare qualche decimo

[krogy80]

Originariamente inviato da flx2000

Nessuna distribuzione, ho compilato ogni singolo programma da zero.

bhe, complimenti!
pensi che i tuoi risultati possono essere riprodotti su arch?
ha un solo script di init e dovrebbe essere facilmente configurabile.

[eclissi83]

Originariamente inviato da flx2000

Chiaramente, lo scopo è quello di imparare a gestire manualmente la configurazione dei processi più delicati di un sistema Linux.
Che poi dia risultati pratici è sicuramente tutto di guadagnato!

ok..

La sospensione utilizza comunque la batteria, quindi è inutile se il portatile non può essere ricaricato fino al giorno dopo. Per questo è stata scartata di base.

sinceramente, mi capita di avere il portatile in standby anche per 2 giorni (quando la batteria era "buona" arrivavo a 4 giorni di standby) per poi doverlo ricaricare necessariamente... pero' boh dipende dalla batteria e dalla gestione della stessa..

L'ibernazione sarebbe una strada alternativa, ma riservare 2Gb di spazio per l'ibernazione su un netbook con disco da 8Gb che scrive a 6Mb/s è controproducente.

non avevo pensato a questo aspetto della cosa...

[flx2000]

Originariamente inviato da krogy80

bhe, complimenti!
pensi che i tuoi risultati possono essere riprodotti su arch?
ha un solo script di init e dovrebbe essere facilmente configurabile.

Sì, sicuramente arch è la distribuzione che meglio si può adattare a questo lavoro.

[Psycotic]

stai gia' utilizzando sysvinit-ng?
un'altra cosa che potrebbe velocizzare, ma nn so di qanto.. forse qalche millisecondo potrebbe essere cambiare la shell, perche' la bash e' un po' esosa.

[Psycotic]

Per quanto riguarda sreadahead ho trovato questo per la lista dei file

find / -type f \( -fstype ext3 -o -fstype rootfs \) > lista.packed.new
/sbin/sreadahead-pack lista.packed.new


Ma io dico... Questo genera un file con dentro tutta la root, anzi dipende come fai le partizioni direi "tutti i file dell'hd" e questo non ha senso!!!! almeno che sreadahead-pack capisca qale siano i file inutili x lui..
Ma cmq e' vero.. c'e' un po' di confusione su quest'argomento.. io nel file lo popolerei con tutto quello che trovi dentro gli script di init e ovviamente le librerie..

Bah.. facci sapere se serve a qualcosa!!

[flx2000]

Il nuovo sreadahead non ha bisogno di creare la lista (il file pack) a mano perché se non presente lo genera in modo automatico, e lo usa dall'avvio successivo in poi.
In questo modo, grazie a una minima modifica in un file del kernel (inclusa nel nuovo sreadahead), cataloga solo i file effettivamente necessari al boot.

Quel comando è per la vecchia versione, infatti specifica ext3 visto che a differenza di quello attuale non funzionava su ext2.

PS: non sto utilizzando sysvinit-ng perché l'esercizio è mirato all'ottimizzazione degli script di boot e questa comprende già la parallelizzazione dei processi di boot.

In ogni caso mi sono fermato a 11 secondi di boot in ambiente grafico. Devo dire che rispetto ai 35-40 necessari prima dell'intervento è già un ottimo guadagno!

[Dane]

nel forum di gentoo si consigliava di usare sh (o busybox ) al posto di bash, se usi initscripts. Hai il "problema" di non poter usare i bashismi negli initscripts


Altra cosa... sempre su gentoo si sta sviluppando openRC, che (se non ho capito male) al posto degli script usa roba compilata in C (con config files esterni ovviamente). La differenza si sente rispetto ai classici scripts, ma è ancora abbastanza testing.


Buon lavoro!

[flx2000]

Originariamente inviato da Dane

nel forum di gentoo si consigliava di usare sh (o busybox ) al posto di bash, se usi initscripts. Hai il "problema" di non poter usare i bashismi negli initscripts


Altra cosa... sempre su gentoo si sta sviluppando openRC, che (se non ho capito male) al posto degli script usa roba compilata in C (con config files esterni ovviamente). La differenza si sente rispetto ai classici scripts, ma è ancora abbastanza testing.


Buon lavoro!

Grazie per le segnalazioni, molto interessanti.
Busybox è un'idea, ma vorrei avere un sistema tradizionale che però si avvi in tempi molto rapidi.
Usare SH al posto di BASH potrebbe dare risultati, magari proverò a vedere. Mi preoccupa solo l'uso massiccio di funzioni tipicamente BASH all'interno degli script di init (ad esempio codici come ${var##.conf} che a replicare su SH si finisce per peggiorare la situazione).

L'init in C invece mi sembra un'ottima idea. A questo punto ero arrivato a pensare che l'ideale fosse avere una sola coppia di script S00 e K00 per ogni runlevel, che caricassero tutti i processi tradizionali in maniera più parallela possibile.
Si sa che il C è più veloce della BASH, quindi potrebbe essere un'ulteriore passo in avanti per questo tipo di approccio a file singolo.

Oggi provo qualcosa e vi faccio sapere.
Grazie!