Come velocizzare l'avvio di Slackware.

Sonic · Messaggio da **Sonic** » dom 12 feb 2006, 21:52

Hey raga, sentite questa!

Sono riuscito a velocizzare l'avvio della mia slackware di ben 7 secondi semplicemente mettendo "&" alla fine di alcuni comandi su rc.M.

In questo modo alcuni processi, invece di essere lanciati in serie, vengono lanciati in parallelo risparmiando tempo! :P

Vi listo i comandi che sono riuscito a lanciare così:
- ldconfig
- fc-cache
- inet1
- cupsd
- dnsmasq
- smartd
- crond
- atd
- apmd
- rc.alsa
- rc.gpm

Ovviamente comandi come rc.hotplug e altri del genere devono necessariamente essere lanciati in serie altrimenti i processi che si appoggiano a questi possono dare errore e non avviarsi (vedi alsa che dipende da rc.hotplug).

Buon divertimento!!

Messaggio da **JohnnyMnemonic** » dom 12 feb 2006, 22:12

In realtà non dovresti risparmiare tempo, semplicemente arrivi prima a vedere la shell o il wm per lavorare ma i processi stanno ancora lavorando.

O sbaglio? sono vaghi ricordi dei miei studi di sistemi operativi ...

Messaggio da **goldy** » dom 12 feb 2006, 22:26

Sonic ha scritto: Sono riuscito a velocizzare l'avvio della mia slackware di ben 7 secondi semplicemente mettendo "&" alla fine di alcuni comandi su rc.M.

È scritto anche su slackwarefordummies

Sonic ha scritto: Ovviamente comandi come rc.hotplug e altri del genere devono necessariamente essere lanciati in serie....

Puoi mettere la & anche ad hotplug

gallows · Messaggio da **gallows** » dom 12 feb 2006, 22:32

Io metto in bg solo ldconfig.
Anche perché il vantaggio di mettere in background roba come gpm o alsa è tutto da dimostrare..
Per velocizzare hotplug comunque credo sia buona norma ricompilare il kernel.

Messaggio da **goldy** » dom 12 feb 2006, 22:42

gallows ha scritto:Io metto in bg solo ldconfig.

io oltre a ldconfig anche hotplug

gallows ha scritto: Anche perché il vantaggio di mettere in background roba come gpm o alsa è tutto da dimostrare..

Concordo

gallows ha scritto:Per velocizzare hotplug comunque credo sia buona norma ricompilare il kernel.

In che senso? cosa bisogna fare di preciso per velocizzare hotplug nel kernel?

gallows · Messaggio da **gallows** » dom 12 feb 2006, 22:47

Snellendo il kernel precompilato. Inserendo i supporti statici dove serve e rimuovendo tutti i moduli inutili.

Messaggio da **goldy** » dom 12 feb 2006, 22:55

gallows ha scritto:Snellendo il kernel precompilato. Inserendo i supporti statici dove serve e rimuovendo tutti i moduli inutili.

Ah ma il kernel l'ho snellito
si in effetti però qualche modulo che non serve ad una cippa mi è rimasto,
ma ero convinto che non portasse ad una perdita di tempo per hotplug,
cioè ero dell'idea che un modulo del kernel finchè non caricato ,stesse li' a non dare nessun fastidio ,neanche in lettura , e pronto ad agire con un semplice modprobe.
Buono a sapersi grazie della info

gallows · Messaggio da **gallows** » dom 12 feb 2006, 23:01

In realtà mi sono spiegato veramente male :P
Quello che influisce sulle prestazioni (secondo me) sono quei supporti inseriti come moduli quando potrebbero essere messi staticamente. (Sono un fautore del kernel semi-monolitico)

I moduli *veramente* inutili sinceramente non so se facciano perdere tempo ad hotplug, ma credo di no (almeno non in maniera apprezzabile).

masalapianta · Messaggio da **masalapianta** » dom 12 feb 2006, 23:09

in aggiunta ai consigli che ti hanno gia dato, se proprio vuoi rosicchiare qualche altro secondo prova init-ng:

http://initng.thinktux.net/index.php/Main_Page

Sonic · Messaggio da **Sonic** » lun 13 feb 2006, 1:15

goldy ha scritto:
gallows ha scritto:Io metto in bg solo ldconfig.
io oltre a ldconfig anche hotplug

A me hotplug non fa partire alsa se lo metto in bg.

gallows ha scritto: Anche perché il vantaggio di mettere in background roba come gpm o alsa è tutto da dimostrare..

Non sono daccordo, certi processi partiranno anche subito ma quel quarto di secondo che impiega ciascun processo per partire poi più sono i processi e più i quarti di secondo si accumulano.

Comunque più che altro quelli che fanno gioco sono ldconfig e fc-cache.

krisis · Messaggio da **krisis** » lun 13 feb 2006, 1:21

Ma mandare in bg un processo non significa farlo partire prima , come ti ha fatto giustamente notare johnny memonic.
Arrivi solo prima a vedere il promt ma il processore sta ancora la a macinare su più cose contemporaneamente.
E poi impiegare 16 secondi o impiegarne 23 per fare il boot ti cambia la vita?

Sonic · Messaggio da **Sonic** » lun 13 feb 2006, 1:56

E hai detto niente!!

Beh, comunque come capirai dal mio nick sono maniaco di certe cose....hehe!! :P

simplex · Messaggio da **simplex** » lun 13 feb 2006, 10:01

Poi dipende tutto anche dalle priorita' che assumono i processi

Raistlin84 · Messaggio da **Raistlin84** » lun 13 feb 2006, 11:20

E' vero che i processi rimangono in background quindi sono sempre a carico del processore, ma arivando al prompt prima si può agire subito.Poi se uno appena arriva lancia un programma talmente peso che il pc deve esser spremuto al massimo, risentirà dei processi lasciati in background che stanno ancora girando.
Ma se uno ad esempio fa come me: si logga poi o avvia lynx o X, controlla la posta, oppure avvia kwrite... a questo punto i processi in background si saranno già esauriti più o meno, quindi secondo me ha senso mettere un pò di roba in background.E' chiaro che mentre ci sono quei servizi in bg i programmi sarano leggermente più lenti, ma neanche troppo.
Comunque io ci tengo ldconfig e la rete, perchè se no quando non sono connesso mi tocca ad aspettare troppo.

Salvo · Messaggio da **Salvo** » lun 13 feb 2006, 14:31

Ricordatevi però che il processore è sempre uno (nella maggior parte dei casi) e le operazioni finiscono sempre allo stesso momento.
Certo che è più comodo loggarsi mentre ldconfig sta lavorando.

slacky.eu

Come velocizzare l'avvio di Slackware.

Come velocizzare l'avvio di Slackware.

Re: Come velocizzare l'avvio di Slackware.