Moduli del kernel inutilizzati

[masteryuri]

Avrei una domanda sui kernel linux:

Cosa comporta l'aggiunta al kernel, in fase di configurazione, di moduli che non servono?
Ad esempio un driver per una scheda di rete che sulla macchina non è presente o il supporto ad un filesystem non usato da alcuna partizione.

Maggior spreco di risorse?
Nessuna differenza?
Un bzImage più grande?
C'è differenza, da questo punto di vista, tra un built-in e un modulo?

In sostanza:
Compilare un kernel linux utilizzando lo stretto indispensabile di moduli è sinonimo di ottimizzazione? Se si, tecnicamente, perché?

Grazie in anticipo per eventuali chiarimenti

[Exeba]

I moduli che non servono non vengono caricati ( a meno di errori nel sistema di caricamento automatico del kernel ), quindi i moduli inutili non fanno alcun danno semplicemente perchè non vengono caricati.

L'unica differenza pratica tra modulo e built-in è che in alcuni casi ti puoi risparmiare l'initrd.
Ad esempio:
Supponiamo di avere due kernel, uno con tutti i filesystem in moduli, l'altro con i filesystem built-in.
Il primo avrà bisogno di un'initrd che carichi il modulo del filesystem (infatti per accedere al modulo dovrebbe accedere al disco, ma non può senza il modulo), l'altro no.
Questo discorso vale anche per i driver del controller dei dischi.

L'unico modulo che utilizzo è quello della scheda video, il resto è built-in (ovviamente solo quello che mi serve). Sinceramente non ho fatto benchmark, non sembra che ci siano miglioramenti evidenti.
Però di certo impari molto sfogliando le configurazioni del kernel.

[sacarde]

http://blog.linux-fueled.com/2008/11...ente-benefici/

http://blog.linux-fueled.com/2008/12...anilla-kernel/

[masteryuri]

Originariamente inviato da Exeba

I moduli che non servono non vengono caricati ( a meno di errori nel sistema di caricamento automatico del kernel ), quindi i moduli inutili non fanno alcun danno semplicemente perchè non vengono caricati.

L'unica differenza pratica tra modulo e built-in è che in alcuni casi ti puoi risparmiare l'initrd.
Ad esempio:
Supponiamo di avere due kernel, uno con tutti i filesystem in moduli, l'altro con i filesystem built-in.
Il primo avrà bisogno di un'initrd che carichi il modulo del filesystem (infatti per accedere al modulo dovrebbe accedere al disco, ma non può senza il modulo), l'altro no.
Questo discorso vale anche per i driver del controller dei dischi.

L'unico modulo che utilizzo è quello della scheda video, il resto è built-in (ovviamente solo quello che mi serve). Sinceramente non ho fatto benchmark, non sembra che ci siano miglioramenti evidenti.
Però di certo impari molto sfogliando le configurazioni del kernel.

Grazie della delucidazione!

Originariamente inviato da sacarde

http://blog.linux-fueled.com/2008/11...ente-benefici/

http://blog.linux-fueled.com/2008/12...anilla-kernel/

Grazie, dò uno sguardo.

[Dane]

Originariamente inviato da masteryuri

Cosa comporta l'aggiunta al kernel, in fase di configurazione, di moduli che non servono?
Ad esempio un driver per una scheda di rete che sulla macchina non è presente o il supporto ad un filesystem non usato da alcuna partizione.

Maggior spreco di risorse?
Nessuna differenza?
Un bzImage più grande?
C'è differenza, da questo punto di vista, tra un built-in e un modulo?

In sostanza:
Compilare un kernel linux utilizzando lo stretto indispensabile di moduli è sinonimo di ottimizzazione? Se si, tecnicamente, perché?

riduci le dimensioni del totale (bzimage o bzimage+moduli).
In teoria dovrebbe caricarsi più velocemente avendo tutto built-in (anche perchè se devi caricare x moduli viene letto x volte il disco).
Se riduci soltanto le opzioni/dimensioni sicuramente si carica più velocemente (tant'è che la maggior parte delle persone che ricompilano avvertono solo questa differenza dopo la ricompilazione).
Abilitando meno opzioni stai (molto) meno tempo a compilare, (se intendi ricompilare più volte per trovare il tune-up perfetto usa ccache specificandolo a riga di comando - superconsigliato dato che risparmi taaaaaaaaaaaaaaaaaaaaaaaanto tempo)

L'ottimizzazione la ottieni ricompilando con cflags più spinte (anche se rischi qualche blocco - valuta se vale la pena andare oltre il solito -O2 oppure -Os previsto dal menuconfig), abilitando, dove possibile ottimizzazioni nel menuconfig per il tuo hardware, scegliendo opportunamente gli scheduler in base al carico di lavoro che hai.

Dal punto di vista della sicurezza avendo il kernel monolitico rischi "meno" che ti venga caricato un rootkit nel kernel. Sottolineo "meno" perchè comunque lo si può fare.
Per come la vedo io, ciò che recuperi ottimizzando il kernel lo puoi "investire" abilitando il PAX/SSP, così fai un po' di hardening. Leggevo di un overhead di circa il 7%....cioè quello che recuperi ottimizzando il kernel.


Se cerchi le prestazioni pure.....ricompila tutto il sistema, prova ad usare ICC al posto di gcc ecc ecc (c'è da divertirsi).


EDIT:
per quello che diceva exeba, riguardo al caricamento dei moduli...
in linea generale sono d'accordo (un modulo non caricato non rallenta/occupa spazio), ma dipende da chi lo carica.
Se disabiliti l'opzione di autoloading dei moduli da parte del kernel e specifichi da qualche parte nell'init quali vanno caricati il discorso non fa una piega (e secondo me è molto pulito).
Se lo fa il kernel in automatico rischi che si incasina qualcosa (ho avuto problemi con kernel modulari e li associo a questo).