Compilare il Kernel

[*andre*]

Originariamente inviato da Gimli[2BV!2B]

Mah, 5 GiB mi sembran proprio troppi. AMD64, per caso?

Per il resto l'unico punto che non mi torna è il 6evi integrare anche i driver IDE/PATA o SATA del tuo chipset e assicurarti che siano integrate le parti SCSI necessarie:

Device Drivers  --->
    SCSI device support  --->
        <*> SCSI disk support
        [*] Asynchronous SCSI scanning
    <*> Serial ATA and Parallel ATA drivers  --->
        [*] SELEZIONARE EVENTUALI FUNZIONALITÀ AGGIUNTIVE, COME ACPI, ecc...
        [*] INDIVIDUARE E SELEZIONARE IL DRIVER CORRETTO

Per individuare velocemente qual'è il driver in uso con il kernel ufficiale puoi usare lspci -k

esatto AMD64..
includerò poi i driver grazie

per adesso sto provando la combinazione più semplice... cioè 2.6.35.24 solo patchati con bfs... vediamo che cosa combina.

da che cosa credi possa dipendere la grandezza spropositata?

[Gimli[2BV!2B]]

Originariamente inviato da *andre*

da che cosa credi possa dipendere la grandezza spropositata?

Dall'architettura a 64 bit. Di solito gli eseguibili finali lievitano di circa un terzo; non avendoci avuto ancora a che fare, ipotizzo che i file di codice oggetto (i .o intermedi) siano molto più cicci.

[*andre*]

Originariamente inviato da Gimli[2BV!2B]

Dall'architettura a 64 bit. Di solito gli eseguibili finali lievitano di circa un terzo; non avendoci avuto ancora a che fare, ipotizzo che i file di codice oggetto (i .o intermedi) siano molto più cicci.

capito
la procedura di compilazione deve essere per forza eseguita da /usr/src/ ? perchè se no sposto tutto nella home e compilo senza problemi... li ho 45 GB ( )

[darkbasic]

Nessun problema se compili da home. Comunque il mio kernel amd64 non è mai andato oltre gli 1/1.5GB...

[Dane]

vi volevo suggerire due dritte per risparmiare tempo:

1 - installate ccache
2 - usatelo: CC="ccache gcc" make
3 - compilate con un -j3 almeno (in genere n° thread possibili+1)

quindi dovreste lanciare (potrei sbagliare perchè non sono sul pingiuno già da un po', in caso controllate)
CC="ccache gcc" make -j4

il -j4 se non ricordo male lancia più processi di gcc insieme. Velocizza sempre.
Ccache mette in cache ciò che avete già compilato. La prima volta che lo lanciate non cambierà nulla. Ma dalla seconda volta in poi, nell'ipotesi che cambiate poche cose alla volta, è capace di ridurre il tempo di compilazione ad 1/4 ;-)
Ovviamente dovete ricordarvi di mettere sempre "il preambolo" CC="......." , altrimenti viene usato direttamente gcc.



icc è problematico con il kernel dato che è stato scritto apposta per funzionare con gcc.
Tuttavia in altri software viaggia di più (che io sappia si usa principalmente per sw multimediali). Attenti alla licenza, i binari compilati con icc hanno qualche limitazione (non mi ricordo se riguarda solo la distribuzione).


happy make! :-)

[*andre*]

grazie a tutti.

comunque ci sono riuscito.. ho spostato tutto nella home e ho compilato il 2.6.37 con la patch e togliendo driver che non servivano..

comunque adesso la cartella linux-2.6.37 da cui ho lanciato la compilazione occupa 5.3GB e i .deb linux-image linux-headers fuori occupano, rispettivamente, 30 e 6.9 MB...

è proprio necessario sviluppare oltre 5GB di dati per un kernel che pesa 30MB?

a questo punto non e che è il fatto che creo .deb il motivo della pesantezza?

[Gimli[2BV!2B]]

@Dane, ma si risparmia davvero qualcosa con ccache?
Gli oggetti restano sempre nella cartella e le compilazioni sono sempre incrementali, tranne in caso di modifica delle rare opzioni che sono #define che girano tutti i sorgenti o parametri di compilazione; in questi casi mi risulta che anche ccache sia costretta a ricompilare.
Se si attiva un driver e si lancia il make in sorgenti già compilati si osserverà la compilazione del solo driver e la rigenerazione di vmlinuz & co, tempo circa un minuto.

Riduce sensibilmente il tempo della prima compilazione di una nuova versione (sorgenti puliti) se ha in cache gli oggetti della precedente?
Quanto occupa la cache?

[Dane]

ccache ha degli algoritmi per minimizzare la roba già compilata. Trovi qualcosa nel man se non ricordo male.


Tiene in cache fino a 2gb di roba. Per arrivare a 2gb ci compili mezza gentoo....

Per la velocità di compilazione....fai una prova

time CC="ccache gcc" make && make clean && time CC="ccache gcc" make

io lo usavo sempre perchè mentre ottimizzavo finivo col cambiare poche cose alla volta, dando sempre il make clean in mezzo (non so se sia necessario). Per velocizzare velocizzava.
Mi pareva che andasse più spedito anche tra una versione e l'altra.

[Gimli[2BV!2B]]

Originariamente inviato da Dane

ccache ha degli algoritmi per minimizzare la roba già compilata.

Sì, fa un hash di ogni singolo file compilato e ne memorizza il rispettivo codice oggetto.
Quando viene richiesta la compilazione di un file fa la ricerca in questo database; se trova una corrispondenza recupera l'oggetto; se non la trova compila, fa l'hash, memorizza e rende l'oggetto.

Originariamente inviato da Dane

Tiene in cache fino a 2gb di roba. Per arrivare a 2gb ci compili mezza gentoo....

Certo, il fatto è che è raro si ricompili la stessa roba in tempi brevi e 2 GiB non mi sembran tanti, pensando solo a bestioni come Chromium e OpenOffice.

Posso dire di non aver mai fatto un make clean nei sorgenti del kernel e di non aver avuto problemi.

Non so... sono estremamente scettico... credo che il lavoro in più che necessita per funzionare compensi a malapena i pochi casi in cui può tornar utile, in caso di utilizzo generalizzato per un intera distribuzione basata sui sorgenti.

Probabilmente utilizzandola solo ed esclusivamente per compilare un gruppo non troppo grande di grossi programmi (come il kernel) può dare vantaggi.

Per finire ho grossi dubbi sulla bontà del risultato se si aggiorna il compilatore o si cambia qualche flag. Va sempre tutto liscio o si rischia di incappare in subdoli problemi?

[Dane]

http://linux.die.net/man/1/ccache

se cambi qualche parametro al compilatore (o si cambia il compilatore) la cache non viene utilizzata, bensì rigenerata.
Fa l'hash del comando che invoca il compilatore, dell'output del precompilatore e altro....

Su gentoo è la prima cosa che si consiglia di installare (chissà perchè ). Non penso proprio che abbia grossi problemi.

Io non ho avuto problemi con ccache. Ne ho avuti di più quando non facevo il clean, a parità di .config (e questo ben prima di giocare con ccache e -jx).

chromium non l'ho mai compilato, ma openoffice è una cosa assurda (l'ebuild filtra tante ottimizzazioni) che richiede 4-5gb di spazio e che non finisce mai.....

[darkbasic]

Chromium + icedtea + openoffice = ci rivediamo fra tre giorni

Comunque molto meglio distcc

[Dane]

Originariamente inviato da darkbasic

Chromium + icedtea + openoffice = ci rivediamo fra tre giorni

Comunque molto meglio distcc

ricordandosi di mettere un -j20 con i processori odierni

quotone per i il "trittico" citato

[Gimli[2BV!2B]]

Mmh, sì, l'hash è un po' più articolato e mi sembra tener conto di tutte le variabili in gioco.

Beh, ricordavo peggio

     Sun Dec  5 20:09:52 2010 >>> app-office/openoffice-3.2.1-r1                                                                                             
       merge time: 7 hours, 25 minutes and 31 seconds.

     Thu Jan 20 05:02:54 2011 >>> www-client/chromium-10.0.634.0-r1
       merge time: 3 hours, 20 minutes and 27 seconds.

11 ore ed è fatta (PIV 2.2GHz).

Originariamente inviato da Dane

ricordandosi di mettere un -j20 con i processori odierni

Orcocàn -j20? Ma non sono un po' troppi venti CC concorrenti anche con un i7 ultra-powa? (Da quando uso il BFS con -j1 su single core i tempi si son ridotti di qualche punto percentuale)

Originariamente inviato da Dane

Su gentoo è la prima cosa che si consiglia di installare (chissà perchè). Non penso proprio che abbia grossi problemi.

Ho letto pareri discordanti a riguardo e molti bug in cui si consigliava di ricompilare disattivandola.
Se l'hai usata assiduamente ed hai riscontrato soprattutto miglioramenti ci faccio un pensiero.

Riguardo ad OpenOffice lo compilo perché avevo notato (mesi, forse anni fa) che quello compilato partiva in tempi sensibilmente inferiori e sembrava più fluido durante l'utilizzo, effettivamente è un mostro
Quali sono le principali differenze dell'ebuild rispetto al binario? Ho solo letto accenni a riguardo ma non ho rintracciato un documento che li mettesse nero su bianco.

Come darkbasic anch'io apprezzo distcc, lì i risultati sono più tangibili e costanti.

[Dane]

Originariamente inviato da 'Gimli[2BV!2B

Orcocàn -j20? Ma non sono un po' troppi venti CC concorrenti anche con un i7 ultra-powa? (Da quando uso il BFS con -j1 su single core i tempi si son ridotti di qualche punto percentuale)

Come fai ad uccidere una formica? Sparando col bazooka.
Come fai a compilare una genttoo per 386 (esagero): con un cluster di i7 (derivano da quello i -j20, anche se sarebbero -j7 per il solo i7, -j13 per due i7, -j20 per 3 i7)

Ho letto pareri discordanti a riguardo e molti bug in cui si consigliava di ricompilare disattivandola.
Se l'hai usata assiduamente ed hai riscontrato soprattutto miglioramenti ci faccio un pensiero.

non ho avuto grossi problemi. Cmq mi hai messo la pulce nell'orecchio..... I problemi c'erano anche su gentoo (perchè penso che in caso verrebbe filtrato il build con ccache).

Riguardo ad OpenOffice lo compilo perché avevo notato (mesi, forse anni fa) che quello compilato partiva in tempi sensibilmente inferiori e sembrava più fluido durante l'utilizzo, effettivamente è un mostro
Quali sono le principali differenze dell'ebuild rispetto al binario? Ho solo letto accenni a riguardo ma non ho rintracciato un documento che li mettesse nero su bianco.

ebuild = serie di istruzioni per compilare, che stanno in portage. Risolvono le dipendenze in base a cosa vuoi abilitare
Negli ebuild i manutentori del pacchetto filtrano eventuali ottimizzazioni troppo spinte.
Con i binari usi quelli distribuiti da oracle o dalla distro, che abilitano più o meno tutto.
Cmq con OOo le funzionalità erano abbastanza incasinate e "conveniva" andarsi a vedere l'ebuild per capire cosa veniva abilitato in base alle flag.

Cmq in genere io ho notato un buon miglioramento di velocità di caricamento compilando con la flag --as-needed al linker. Se non sbaglio prima era una flag consigliata ufficiosamente, adesso ufficialmente (gentoo forever!).

[darkbasic]

Originariamente inviato da Gimli[2BV!2B]

11 ore ed è fatta (PIV 2.2GHz).

Bazzeccole
Personalmente mi fa venire il nervoso ogni volta che compila perché è anche un ciucciaram/frulladisco pauroso, quindi mi tengo il mio caro app-office/libreoffice-bin-3.3.0

Originariamente inviato da Gimli[2BV!2B]

Ho letto pareri discordanti a riguardo e molti bug in cui si consigliava di ricompilare disattivandola.

Infatti, i problemi sono già abbastanza senza...

Originariamente inviato da Gimli[2BV!2B]

Come darkbasic anch'io apprezzo distcc, lì i risultati sono più tangibili e costanti.

Specie quando l'aiutino viene da uno di questi

root@xen-dom0:~# cat /proc/cpuinfo 
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 26
model name      : Intel(R) Xeon(R) CPU           W3520  @ 2.67GHz
stepping        : 5
cpu MHz         : 2726.474
cache size      : 8192 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nonstop_tsc aperfmperf pni est ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm ida
bogomips        : 5452.94
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 1
vendor_id       : GenuineIntel
cpu family      : 6
model           : 26
model name      : Intel(R) Xeon(R) CPU           W3520  @ 2.67GHz                                                                                                                   
stepping        : 5                                                                                                                                                                 
cpu MHz         : 2726.474                                                                                                                                                          
cache size      : 8192 KB                                                                                                                                                           
fpu             : yes                                                                                                                                                               
fpu_exception   : yes                                                                                                                                                               
cpuid level     : 11
wp              : yes
flags           : fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nonstop_tsc aperfmperf pni est ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm ida
bogomips        : 5452.94
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 2
vendor_id       : GenuineIntel
cpu family      : 6
model           : 26
model name      : Intel(R) Xeon(R) CPU           W3520  @ 2.67GHz
stepping        : 5
cpu MHz         : 2726.474
cache size      : 8192 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nonstop_tsc aperfmperf pni est ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm ida
bogomips        : 5452.94
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 3
vendor_id       : GenuineIntel
cpu family      : 6
model           : 26
model name      : Intel(R) Xeon(R) CPU           W3520  @ 2.67GHz
stepping        : 5
cpu MHz         : 2726.474
cache size      : 8192 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nonstop_tsc aperfmperf pni est ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm ida
bogomips        : 5452.94
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 4
vendor_id       : GenuineIntel
cpu family      : 6
model           : 26
model name      : Intel(R) Xeon(R) CPU           W3520  @ 2.67GHz
stepping        : 5
cpu MHz         : 2726.474
cache size      : 8192 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nonstop_tsc aperfmperf pni est ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm ida
bogomips        : 5452.94
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 5
vendor_id       : GenuineIntel
cpu family      : 6
model           : 26
model name      : Intel(R) Xeon(R) CPU           W3520  @ 2.67GHz
stepping        : 5
cpu MHz         : 2726.474
cache size      : 8192 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nonstop_tsc aperfmperf pni est ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm ida
bogomips        : 5452.94
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 6
vendor_id       : GenuineIntel
cpu family      : 6
model           : 26
model name      : Intel(R) Xeon(R) CPU           W3520  @ 2.67GHz
stepping        : 5
cpu MHz         : 2726.474
cache size      : 8192 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nonstop_tsc aperfmperf pni est ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm ida
bogomips        : 5452.94
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

processor       : 7
vendor_id       : GenuineIntel
cpu family      : 6
model           : 26
model name      : Intel(R) Xeon(R) CPU           W3520  @ 2.67GHz
stepping        : 5
cpu MHz         : 2726.474
cache size      : 8192 KB
fpu             : yes
fpu_exception   : yes
cpuid level     : 11
wp              : yes
flags           : fpu de tsc msr pae mce cx8 apic sep mtrr mca cmov pat clflush acpi mmx fxsr sse sse2 ss ht syscall nx lm constant_tsc rep_good nonstop_tsc aperfmperf pni est ssse3 cx16 sse4_1 sse4_2 popcnt hypervisor lahf_lm ida
bogomips        : 5452.94
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

[darkbasic]

Originariamente inviato da Dane

Cmq in genere io ho notato un buon miglioramento di velocità di caricamento compilando con la flag --as-needed al linker. Se non sbaglio prima era una flag consigliata ufficiosamente, adesso ufficialmente (gentoo forever!).

No, è proprio una flag attiva di default ora

[Dane]

Originariamente inviato da darkbasic

No, è proprio una flag attiva di default ora

pardon

cmq ti credo che con quella roba viaggia più distcc

[Gimli[2BV!2B]]

Dark, mi sembri attrezzato... con quello il tempo più lungo è quello per scaricare il tar.bz2

[darkbasic]

Scherzaci... è corredato di un SSD Intel gen2 e controller sas 8 porte, compila il kernel debian in 4 minuti e spicci

[Dane]

Originariamente inviato da darkbasic

Scherzaci... è corredato di un SSD Intel gen2 e controller sas 8 porte, compila il kernel debian in 4 minuti e spicci

solo un ssd?