esperimenti con il boot di Slackware

[ksniffer]

Una volta ho anche provato a compilare tutti gli script sh, ma la differenza di prestazioni è trascurabile quindi non mi sento di consigliartelo.

Compilare un bash, mica è C/C++ che si compila? E come si farebbe?

[ksniffer]

@ Mario Vanoni:
9:63 sec - tasto power --> lilo prompt
3:00 sec - attesa di lilo
19.59 sec - lilo --> init 3 login
26:66 sec - lilo --> init4 login

ci sto circa 10 secondi in meno del tuo tempo se parto in init4 e circa 15 se parto in init3... Il mio laptop è un Intel celeron 550 2.0GHz con 512MB ram, 80GB Hard Disk S-Ata, quindi molto meno potente dei tuoi pc...


E secondo me si può scendere ancora, mi sapete dire in che ordine vengono lanciati gli script di init su Slackware?? cosa c'è a monte di rc.S??


ciau...

Scusa se sono pignolo, ma va fatto un confronto tra il prima di modificare lo script e il dopo aver modificato lo script, così da capire quanti secondi hai guadagnato...
Ci mostri le due tabelle? Son curioso.
Grazie

[FireEater]

Compilare un bash, mica è C/C++ che si compila? E come si farebbe?

Mai sentito parlare di shc? Permette di conversioni bash to c. Quindi si, anche il bash si compila

Leggo proprio ora che questo convertitore non rende nessun beneficio in termini di velocità rispetto allo script originale dato che è stato creato per un altro scopo.
Lo scopo originale è rendere possibile l'inserimento di una data di scadenza all'interno dello script.

[danix]

Scusa se sono pignolo, ma va fatto un confronto tra il prima di modificare lo script e il dopo aver modificato lo script, così da capire quanti secondi hai guadagnato...
Ci mostri le due tabelle? Son curioso.
Grazie

Eccoti servito
I primi 2 tempi sono gli stessi, la parte gustosa arriva da lilo in poi, con rc.S e rc.M originali:
lilo --> init 3 login - 28:46 sec
lilo --> init 4 login - 36:38 sec

I tempi li ho presi cronometro alla mano, quella discrepanza di un secondo più o meno in init4 credo sia dovuta al momento in cui ho stoppato il crono, ma in ogni caso la sostanza rimane, quasi 10 secondi di differenza tra gli rc originali e quelli modificati...


Chissà quanto posso migliorare il tempo sul giro...

[Mario Vanoni]

chmod 0000 rc.local
reboot
da lilo al login 10 secondi in meno
chmod 0755 rc.local
time rc.local
0m9.329s

[danix]

Mario, pensa allora quanto potresti risparmiare modificando rc.S e rc.M... Io rc.local non lo uso proprio...

Ovviamente sto parlando tanto per scambiare qualche parere, non ho nessun interesse a far modificare gli script di Slackware a qualcuno, è interessante solo vedere quanto sia elastico un sistema GNU/Linux...

[gigiobagiano]

Beh, in realtà fare un'operazione di questo genere su altri sistemi GNU/Linux è più complicato...almeno per mia esperienza personale...

[albatros]

Secondo me non è questione di tempo speso per il testing dell'eseguibilità di un files, quanto il fatto che venivano eseguiti realmente degli script in /etc/rc.d perché appunto eseguibili.
Ho buttato giù il seguente banalissimo script (chiamato appunto script) che fa alcuni test sui files in /etc/rc.d, li mostra se eseguibili, li conta e perde tempo a stampare l'elenco dei processi:

Codice: Seleziona tutto

pista="/etc/rc.d/";
conta=0;  dire=0; tot=0;
for i in $pista*;
do if [ -x $i ]; then echo $i; cat $i; conta=$((conta+1)); fi;
if [ -d $i ]; then dire=$((dire+1)); fi;
if [ -f $i ]; then tot=$((tot+1)); ps -ax; fi;
done;
echo; echo "Elencati $conta files eseguibili, $dire directory e $tot file normali";

Riporto le ultime due righe di output di

Codice: Seleziona tutto

time ./script

Elencati 28 files eseguibili, 8 directory e 47 file normali

real 0m0.383s
user 0m0.120s
sys 0m0.130s

Come vedi si tratta di tempi minimi e lo script fa molto di più che controllare l'eseguibilità dei files...

Secondo me è preferibile lasciare le cose come sono, al limite commentando qualche riga, e limitarsi a dare chmod -x ai servizi che non interessano, la gestione e gli aggiornamenti risulteranno più facili, ma si tratta di preferenze personali, neanch'io, in fondo, faccio sempre le cose come originariamente previsto dalla slackware...

Però, ripeto, la motivazione dev'essere di ordine pratico, perché ti trovi meglio, non perché il boot è più veloce...

Mario nel suo rc.local avrà probabilmente qualche comando che richiede tempo per essere eseguito, nel mio caso:

Codice: Seleziona tutto

time /etc/rc.d/rc.local

real    0m0.017s
user    0m0.010s
sys     0m0.007s

Perché viene eseguito solo:

Codice: Seleziona tutto

sensors -s
modprobe cpufreq_conservative

[sardylan]

[...] Una volta ho anche provato a compilare tutti gli script sh, ma la differenza di prestazioni è trascurabile quindi non mi sento di consigliartelo. [...]

Compilare in che senso???

comunque Danix mi hai dato una buna idea!! Ora vedo che cosa si può togliere o no!!!

[FireEater]

[...] Una volta ho anche provato a compilare tutti gli script sh, ma la differenza di prestazioni è trascurabile quindi non mi sento di consigliartelo. [...]

Compilare in che senso???

Riporto quello che ho già scritto sopra in risposta a ksniffer:

Mai sentito parlare di shc? Permette di conversioni bash to c. Quindi si, anche il bash si compila

Leggo proprio ora che questo convertitore non rende nessun beneficio in termini di velocità rispetto allo script originale dato che è stato creato per un altro scopo.
Lo scopo originale è rendere possibile l'inserimento di una data di scadenza all'interno dello script.

[danix]

In effetti immaginavo che il tempo maggiore non l'avessi recuperato togliendo l'if ma commentando proprio tutto quello che so di non usare, vedi lvm, isapnp ecc... però anche in termini di usabilità non ci perdo nulla perchè in caso di aggiornamento dovrò comunque andare a ricontrollare gli script... e poi l'usabilità è soggettiva... per me usabile potrebbe essere un'interfaccia grafica, per Mario un file di testo (un esempio a caso)...

grazie degli interventi comunque... mi fa piacere che l'argomento risulti interessante...

[Mario Vanoni]

Mario, pensa allora quanto potresti risparmiare modificando rc.S e rc.M... Io rc.local non lo uso proprio...

Ovviamente sto parlando tanto per scambiare qualche parere, non ho nessun interesse a far modificare gli script di Slackware a qualcuno, è interessante solo vedere quanto sia elastico un sistema GNU/Linux...

Uso rc.local e rc.local_shutdown
per avere un sistema che funziona come voglio io.

Incuriosito ho guardato rc.S:
ci sono 33 "if [ ..."
dei quali 17 mai usati da me,
quindi danno risultato falso.

cat .z

Codice: Seleziona tutto

#!/bin/sh
if [ 9 -eq 0 ]
then
: # do nothing
fi

time .z
0m0.006s

moltiplicato per 17 = 0m0.102s
con un Core 2 Dual con 4096KB L2 cache e 4GB RAM.

Danilo
quanto tempo guadagno cancellando queste righe?
Vale il lavoro?

[danix]

[...]
Danilo
quanto tempo guadagno cancellando queste righe?
Vale il lavoro?

Mario hai pienamente ragione riguardo agli if, come ho già scritto il tempo non lo si guadagna togliendo quelle ma commentando tutta la roba che non si usa... se non usi lvm, e sai che non lo userai perchè lasciare li tutta quella porzione di codice... stessa cosa per hostname o per tante altre cose...
Del resto non sto parlando per partito preso ma in base ad un guadagno non da poco... 10 secondi rispetto agli script originali secondo me vale i 10 minuti spesi a commentare e i 20 o 30 minuti spesi a fare qualche ricerca su internet per capire cosa fosse questo o quel servizio prima di decidere se lasciarlo o toglierlo...

[conraid]

stessa cosa per hostname

Io l'hostname lo setterei

[Unicondor]

Anche io sono un po meravigliato dei 10 secondi guadagnati...

Il bash come qualsiasi altro linguaggio compilato o interpretato , se non risulta vera l'argomento passato non entra proprio in quella porzione di codice, quindi o il file ha 10000 righe o 3 righe ,il jump nella memoria virtuale ha lo stesso costo di tempo di cpu..perche deve semplicemente passare da una locuzione di memoria ( virtuale ) ad un'altra...

Per questo motivo mi sembrano esagerarti quei 10 sec guadagnati...non vorrei che eliminando qualche if non fai partire qualche demone che invece prima partiva...

A presto

Flavio