Compilare il Kernel

[Emalele1688]

Di nuovo Salve a tutti :)
E ormai quasi un anno che mi sono avventurato nel mondo GNU/Linux, provato diverse distro, smanettato con terminali, tools grafici e non di ogni tipo, programmato pagine e pagine di C++, ed ora sono di fronte a un qualcosa che per me è un enigma:

Compilare il Kernel Linux e ottimizzarlo per il proprio hardware ...

La distro che uso per il test chiaramente è Ubuntu, Ovviamente ho già una Linux Image installata sul sistema (questa che uso ora) e se qualcosa andrà storto posso sempre ricorrere al boot con il kernel che appunto uso ora ...

Vorrei solo sapere se conoscete qualche posto dove posso reperire informazioni riguardo l'ottimizzazione del kernel, perché ho capito che pur conoscendo il mio Hardware, non so quali parametri devo passare ...

Una seconda cosa è: patch zen e patch BFS Scheduler; ho capito cosa serve la seconda, ma non so dove reperirla, mentre la zen per cosa è concepita?

[Gimli[2BV!2B]]

Recente discussione sull'argomento (http://www.hwupgrade.it/forum/showthread.php?t=2280886), con introduzione ai passi consigliabili per una prima compilazione.
Guida ufficiale Ubuntu alla compilazione del kernel. (https://help.ubuntu.com/community/Kernel/Compile)

Compilare il Kernel Linux e ottimizzarlo per il proprio hardware ...
Riassumendo, la compilazione di un kernel su misura si articola solitamente in questi punti:
avere un po' di famigliarità con il sistema operativo e, preferibilmente, dei file che compongono il kernel e relative posizioni
raccogliere informazioni sui driver utilizzati dalla macchina con il kernel stock, più eventuali funzionalità accessorie che si reputano necessarie/interessanti
(opzionale) scegliere una o più patch, più o meno sperimentali, che si desidera provare
predisporre il sistema per la compilazione
procurarsi sorgenti e patch
predisporre l'ambiente di compilazione ed i sorgenti
configurare e compilare
(opzionale) il nuovo kernel non funziona... :(
(opzionale) configurare e compilare
(opzionale) ripetere le ultime due... :muro:
successo! :D
non mi accontento! Configurare e compilare
aggiornare sorgenti
configurare e compilare
ripetere le ultime due...


La distro che uso per il test chiaramente è Ubuntu, Ovviamente ho già una Linux Image installata sul sistema (questa che uso ora) e se qualcosa andrà storto posso sempre ricorrere al boot con il kernel che appunto uso ora ...Esatto, tra l'altro ti consiglio di utilizzare la configurazione del kernel Ubuntu come trampolino di lancio.
Devo segnalarti che con un kernel vanilla (kernel.org) su Ubuntu noterai:
tempi di boot più lunghi dai 2 ai 10 secondi (credo dipenda da patch specifiche nate da un progetto fast boot di qualche tempo fa)
niente grafica bellina durante il boot, ma messaggi del kernel a vista (salvo clonare questa funzionalità)


Vorrei solo sapere se conoscete qualche posto dove posso reperire informazioni riguardo l'ottimizzazione del kernel, perché ho capito che pur conoscendo il mio Hardware, non so quali parametri devo passare ...Non so consigliarti una risorsa unica, perché non è mia abitudine ricercare una sola fonte di informazione.
Come ho già scritto, ottenuto il primo kernel funzionante, considero le seguenti iterazioni di affinamento un "arte del togliere".
Usualmente procedo in questo modo:
leggo il nome dell'impostazione
se non mi dice nulla leggo la descrizione
se non riesco comunque a capire a che serve cerco in internet
controllo se è attiva nel mio sistema, valuto se mi servirà oppure se il valore impostato si addice al mio utilizzo
sono certo che non mi serva e che non mi servirà nell'immediato futuro, oppure determino un nuovo valore che reputo migliore? La disattivo o la modifico
test del risultato
Ti consiglio di fare backup delle configurazioni buone che ottieni (basta salvare il file .config che si trova nella radice di un kernel configurato).

Una seconda cosa è: patch zen e patch BFS Scheduler; ho capito cosa serve la seconda, ma non so dove reperirla, mentre la zen per cosa è concepita?La zen la conosco giusto di nome, mai provata, ma mi risulta sia una raccolta di varie patch che offrono potenziali migliorie in varie sezioni del kernel.
Qui trovi il BFS di CK (http://ck.kolivas.org/patches/bfs/), l'unica patch che sto usando al momento e di cui sono pienamente soddisfatto.

[Emalele1688]

Davvero grazie hai tolto ogni mio dubbio per il momento :)
Ora procederò con il raccogliere informazioni e guide riguardo la compilazione, e se avrò problemi proverò a postarli :D

[Cobra78]

@Gimli[2BV!2B]

Ti assicuro che i passi 8,9 e 10 sono obbligatori per almeno due o tre volte :sofico:

[Gimli[2BV!2B]]

@Emalele1688, noi ci siamo :)

@Cobra78, io sono ottimista! :O
Partendo dalla configurazione della distribuzione, considero buone le probabilità di creare un kernel funzionante. Io l'ho azzoppato molto più spesso sperimentando nelle iterazioni successive!

[Cobra78]

;33966161']@Emalele1688, noi ci siamo :)

@Cobra78, io sono ottimista! :O
Partendo dalla configurazione della distribuzione, considero buone le probabilità di creare un kernel funzionante. Io l'ho azzoppato molto più spesso sperimentando nelle iterazioni successive!

Si ma a suo tempo pensai "se lascio la config uguale che ricompilo a fare? Smandruppiamo tutto subito" :doh:

[Gimli[2BV!2B]]

Io di solito parto tranquillo, il pasticcio più ignorante l'ho fatto quando ho scoperto CONFIG_EMBEDDED.
Ho disattivato in una volta sola printk ed un'altro paio di funzionalità fondamentali, perché ero molto curioso di vedere che succedeva... beh, il sistema ha provato a partire, ma si è dovuto arrendere molto presto :asd:
Sempre quella volta avevo rimosso anche CONFIG_SYSVIPC: me ne sono ricordato quando, settimane dopo, ho provato ad avviare per una mezz'ora buona Apache distribuendo varie benedizioni...

[Cobra78]

Beh, io di recente mi ero incaponito ad eliminare l'initrd........ma ho la root su lvm -.-''

[Gimli[2BV!2B]]

LVM, non l'ho ancora mai provato, ma il concetto di fondo è molto intrigante.
Ho letto che Grub 2 dovrebbe permettere di montare direttamente volumi LVM, permettendo di mettere perfino /boot in LVM o RAID. (http://grub.enbug.org/LVMandRAID)

Alla fine l'initrd è un passaggio piuttosto leggero, ma sono sempre dell'avviso che è meglio ridurre al minimo i componenti di un sistema: ogni pezzo in meno è un pezzo che non si può rompere.
Questo pensiero però mi frena un po' anche nel mio modo di pormi in rapporto ad LVM e RAID (in ambito domestico, naturalmente, al lavoro sono altri ad occuparsi dei macchinoni...).

[Cobra78]

Si beh, però io gioco parecchio (a casa e a lavoro) con la virtualizzazione, e lvm serve per rednere flessibile il raid0 che ho sul portatile :)

Grub2 me lo sono trovato con Ubuntu, e lo giudico troppo acerbo, tant'è che ho rimesso l'uno :P

[Emalele1688]

Allora sto seguendo questa guida per la compilazione del kernel:

http://linuxiano.wordpress.com/2007/03/19/howto-ricompilare-kernel/

Diciamo che spiega tutto ciò che mi servirebbe per partire, ma secondo voi è attendibile??

Non riesco a capire se la patch BFS viene applicata;
Ho scaricato il file patch-2.6.4-ck2.bz2 (che non so nemmeno se è quello giusto), messo nella cartella /usr/src/linux-source-2.6.32/scripts e dato da terminale :
bzcat patch-2.6.4-ck2.bz2

E' il procedimento giusto per patchare il kernel?

ps: Scusate l'ignoranza ma sono alle prime armi con l'argomento...

[Gimli[2BV!2B]]

La guida che riporti non mi convince molto, soprattutto quando si tratta di applicare la patch.

Prima di tutto mi sembra di capire che hai scelto di utilizzare i sorgenti della tua distribuzione, visto che citi la cartella /usr/src/linux-source-2.6.32

In questo caso si è meno certi del risultato dell'applicazione della patch, in quanto i sorgenti sono già modificati dagli sviluppatori della distribuzione e potrebbero contenere modifiche incompatibili con quelle che si desiderano applicare.

Cercherò di chiarire l'argomento.
la mia sequenza di comandi usuale è questa (esempio su aggiornamento ultimo kernel):

cd /usr/src
wget http://www.kernel.org/pub/linux/kernel/v2.6/incr/patch-2.6.36.1-2.bz2
bunzip -k patch-2.6.36.1-2.bz2
patch -d linux-2.6.36.1 -p1 < patch-2.6.36.1-2
mv linux-2.6.36.1 linux-2.6.36.2
rm linux
ln -s linux-2.6.36.2 linux

Vale a dire:
vado nella cartella dei sorgenti
scarico la patch (in questo caso l'incrementale vanilla)
se la patch è compressa in bz2, come in questo caso, la scompatto senza rimuovere il file bz2 (sono sempre piuttosto conservativo in questi processi)
applico la patch, l'output avvertirà di aventuali errori
aggiorno il nome della cartella dei sorgenti
aggiorno il link standard ai sorgenti


La patch CK
Occorre scaricare da qui (http://ck.kolivas.org/patches/bfs/) quella relativa al kernel con la versione più vicina possibile a quello che si desidera.
C'è anche da tener conto della versione dello scheduler (al momento la più recente è la 360).
Di quelle presenti la più semplici da utilizzare sono quelle denominate 2.6.XX[.X]-sched-bfs-XXX.patch:

2.6.XX[.X] indica la versione del kernel a cui sono applicabili; varie volte è possibile utilizzarle su varie revisioni; per questo ho evidenziato l'ultimo numero con le quadre, perché è potenzialmente opzionale
sched-bfs indica che si tratta proprio dello scheduler bfs che ci interessa
l'XXX finale indica le versione dello scheduler; deve esserne indicata una sola, in presenza di due separate da un trattino e/o altre revisioni ci si trova davanti ad una patch incrementale.
Questa permette di aggiornare lo scheduler in sorgenti già patchati con la revisione più vecchia indicata (la cosa funziona a catena e permette di non ripartire da zero).


Esempi:

Incrementale: sul portatile, ho applicato la 2.6.36-sched-bfs-357-1.patch (http://ck.kolivas.org/patches/bfs/2.6.36/2.6.36-sched-bfs-357-1.patch) ai sorgenti 2.6.36.1 (un paio di settimane fa).
Ora, per aggiornare incrementalmente il solo scheduler, potrei utilizzare la 2.6.36-sched-bfs-357-1-360.patch (http://ck.kolivas.org/patches/bfs/2.6.36/2.6.36-sched-bfs-357-1-360.patch) che porterebbe il bfs dalla versione 357-1 alla 360.
Faccio anche notare che si può tentare di utilizzare la patch-2.6.36.1-2, riportata nei comandi di esempio, per aggiornare la versione del kernel; c'è però il rischio che ne fallisca l'applicazione, rendendo necessario ripartire con i sorgenti puliti, utilizzando quindi la patch bfs completa (vedi punto successivo)
Standard: Partendo invece dai vanilla 2.6.36.2 si potrebbe applicare direttamente la 2.6.36.2-sched-bfs-360.patch (http://ck.kolivas.org/patches/bfs/2.6.36/2.6.36.2-sched-bfs-360.patch)

[Emalele1688]

Grazie infinite della soddisfacente risposta, seguirò a pieno i tuoi consigli, ma una perplessità:
Usando quindi il kernel vanilla i moduli dei driver inseriti dagli sviluppatori di ubuntu (per esempio scheda di rete, stampanti ecc...) non saranno più presenti nel sistema, quindi ci potrebbe essere la possibilità che alcune periferiche non saranno più riconosciute "al volo"?

[Gimli[2BV!2B]]

Ho dato una scorsa alla patch Ubuntu del kernel Ubuntu Maverick più recente (http://packages.ubuntu.com/source/maverick/linux), 2.6.35-23.41 al momento.
È una bella bestiola di circa 15.6 MiB.
Ripulendo della roba priva di significato concreto si scende a 1.5 MiB.

Principali aggiunte:
AppArmor (trascurato nel conto delle dimensioni visto che è integrato nel kernel 2.6.36)
Intel "intelligent power sharing" (http://web.archiveorange.com/archive/v/UsR4nKtmdKd5GUNy49us)
aggiornamenti al comparto video (varie aggiunte alle Intel, da i915 a G45 a SandyBridge; vari aggiornamenti anche ai driver Radeon open)
alcune aggiunte ai driver per il monitoraggio dei sensori hardware
svariate aggiunte al comparto USB
LIRC (http://www.lirc.org/)
un po' di driver per schede di acquisizione multimediali
una discreta quantità di piccole correzioni, tra patch per specifici errori, riduzioni di test prestazionalmente onerosi ed altri piccoli accorgimenti prestazionali
ho trovato anche questa breve lista di driver, che considero tra quelli potenzialmente più interessanti:
+#
+# Makefile for the Linux kernel ubuntu supplied third-party device drivers.
+#
+
+obj-$(CONFIG_AUFS_FS) += aufs (http://en.wikipedia.org/wiki/Aufs)/
+obj-$(CONFIG_BLK_DEV_COMPCACHE) += compcache (http://code.google.com/p/compcache/)/
+obj-$(CONFIG_DM_RAID45) += dm-raid4-5 (http://en.gentoo-wiki.com/wiki/RAID/dm-raid45)/
+obj-$(CONFIG_FSAM7400) += fsam7400 (http://legolas558.iragan.com/index.php?option=content&pcontent=1&task=view&id=34&Itemid=91)/
+obj-$(CONFIG_SCSI_ISCSITARGET) += iscsitarget (http://iscsitarget.sourceforge.net/)/
+obj-$(CONFIG_NDISWRAPPER) += ndiswrapper (http://sourceforge.net/apps/mediawiki/ndiswrapper/index.php?title=Main_Page)/
+obj-$(CONFIG_OMNIBOOK) += omnibook (http://sourceforge.net/apps/mediawiki/omnibook/index.php?title=Main_Page)/
+obj-$(CONFIG_RTL8192SE) += rtl8192se (http://www.realtek.com.tw/products/productsView.aspx?Langid=1&PNid=21&PFid=48&Level=5&Conn=4&ProdID=230)/


Nel complesso credo di poter affermare che, se la macchina che stai usando non è particolarmente recente, non dovresti riscontrare differenze per quanto riguarda il supporto hardware.
Potresti avere problemi nel caso in cui tu abbia a che fare con modem USB o schede di rete wireless per cui ti occorre NDISWrapper.
Potresti avere fastidi anche se usi Ubuntu su di un portatile (un bella fetta delle piccole aggiunte sono quirk per portatili, cioè aggiunte di casi particolari per hardware che non aderisce pienamente alle specifiche).

[Emalele1688]

Allora mi sto dando alla compilazione del kernel Vanilla co la patch BSF.
Sto seguendo questo How To: http://www.ok--computer.com/linux/kernel/kernel2_6.html

Però c'è una cosa che non riesco a capire:
Viene detto che una volta configurato il proprio kernel, (cosa che io faccio con make gconfig), per evitare che qualche opzione sfugga bisogna dare make oldconfig; Ma cosi facendo non viene sovrascritta la nostra nuova configurazione con una precedente?

[Gimli[2BV!2B]]

Il make oldconfig prende il .config che trova e lo aggiorna con le voci presenti nei sorgenti. È un passo necessario per assicurarsi che la configurazione sia valida.

Non è un'operazione distruttiva: se i sorgenti contengono nuove opzioni viene chiesto esplicitamente all'utente come le vuole impostare; naturalmente se alcune opzioni sono state rimosse queste vengono eliminate silenziosamente.

Questo discorso è valido soprattutto in caso di salto di versione centrale (2.35 -> 2.36, per esempio) oppure in caso di applicazione di patch come la BFS, che introduce alcune voci alla configurazione.

Per scrupolo io lo eseguo ad ogni aggiornamento (è una cosa molto veloce).

Come ho già accennato è consigliabile tenere backup dei .config delle due o tre versioni principali precedenti, come anche nei casi di modifiche sostanziali che potrebbero non portare ai risultati desiderati.

[Emalele1688]

Scusa non so se sbaglio, ma ogni volta che eseguo oldconfig mi da una sfilza di voci da confermare con y,m,n; L'altra volta ho impiegato circa un ora.
E' una cosa normale ?

Forse la precedente configurazione del kernel la devo includere io nella directory dei sorgenti, copiandola da /boot (/boot/config-2.6.35-24-generic) e rinominarla in .config ??

[Gimli[2BV!2B]]

Sì, devi mettere nei sorgenti il .config che vuoi aggiornare alla nuova versione.

Riguardo alla quantità di richieste, più il .config è vecchio rispetto ai sorgenti, più si avranno nuove opzioni da configurare.

Ho trovato questo comando che risponde con un invio a tutte le richieste:yes "" | make oldconfigNel caso non l'avesi notato, l'opzione evidenziata col maiuscolo è quella consigliata ed è sufficiente premere invio per accettarla.

[Emalele1688]

OK grazie tanto:)

Ecco i passi che sto eseguendo:
1-Scarico la sorgente del Kernel Vanilla dal sito ufficiale (linux-2.6.36.2);
2-Scarico la patch BFS (2.6.36.2-sched-bfs-360.patch);
3-Decomprimo dentro /usr/src i sorgenti del kernel e copio la patch;
4-Da terminale muovendomi in /usr/src eseguo: patch -d linux-2.6.36.2 -p1 < 2.6.36.2-sched-bfs-360.patch;
5-Dopo mi copio la vecchia configurazione del kernel nella directory dei nuovi sorgenti: sudo cp /boot/config-2.6.35-24-generic .config;
6-Do il comando make oldconfig e rispondo a tutte le richieste (per ora premo invio ad ogni richiesta cosi da lasciare quella consigliata)

Qui mi si presenta un dubbio:
Nella cartella dei sorgenti trovo un file .config ed un file .config.old; Il .config.old posso eliminarlo? così che magari nel menu di boot non mi trovo due configurazioni diverse per lo stesso kernel che ho compilato.
Oppure è conveniente tenerselo il .config.old una volta configurato il Kernel?

7-Do il comando make e aspetto qualche oretta che il kernel si compila;
8-Compilo ed installo i moduli: sudo make modules_install
9-Installo il nuovo kernel: sudo make install;

Pensate che per ora il mio procedimento sia adeguato?

[Gimli[2BV!2B]]

1-Scarico la sorgente del Kernel Vanilla dal sito ufficiale (linux-2.6.36.2);
2-Scarico la patch BFS (2.6.36.2-sched-bfs-360.patch);
3-Decomprimo dentro /usr/src i sorgenti del kernel e copio la patch;
4-Da terminale muovendomi in /usr/src eseguo: patch -d linux-2.6.36.2 -p1 < 2.6.36.2-sched-bfs-360.patch;
5-Dopo mi copio la vecchia configurazione del kernel nella directory dei nuovi sorgenti: sudo cp /boot/config-2.6.35-24-generic .config;
6-Do il comando make oldconfig e rispondo a tutte le richieste (per ora premo invio ad ogni richiesta cosi da lasciare quella consigliata)
Ok.
Qui mi si presenta un dubbio:
Nella cartella dei sorgenti trovo un file .config ed un file .config.old; Il .config.old posso eliminarlo? così che magari nel menu di boot non mi trovo due configurazioni diverse per lo stesso kernel che ho compilato.
Oppure è conveniente tenerselo il .config.old una volta configurato il Kernel?Il .config.old lo puoi praticamente ignorare: non lo caricherà mai di sua spontanea volontà e mantiene semplicemente il salvataggio precedente al .config
7-Do il comando make e aspetto qualche oretta che il kernel si compila;
8-Compilo ed installo i moduli: sudo make modules_install
9-Installo il nuovo kernel: sudo make install;Qualche oretta? Hai un Pentium III?
In Ubuntu non sceglierei la strada classica ma creerei dei bei .deb a là Debian (http://guide.debianizzati.org/index.php/Debian_Kernel_Howto), ma è questione di gusti.
Nulla da eccepire sui comandi di compilazione classica e la loro sequenza.

[Emalele1688]

La prova è su un Athlon X2 4600+, il tempo di compilazione è di circa un'ora e mezza seguendo quei passaggi.. E' normale ??

Si forse il metodo Debian sarebbe ideale;
Ma ogni volta che rinstallo il kernel (make install_modules e make install per intendere) devo eliminare quello precedente della stessa versione o viene automaticamente sovrascritto?
Precisamente per creare un .deb come dovrei muovermi una volta compilato il kernel?

[Gimli[2BV!2B]]

La prova è su un Athlon X2 4600+, il tempo di compilazione è di circa un'ora e mezza seguendo quei passaggi.. E' normale ??Qualche oretta l'ho inteso con minimo 2-3 ore, un'ora e mezza per un kernel bello ciccio come quello nativo di Ubuntu ci sta, ma mi sembra un tempo da single core.
Trattandosi di un dual core mi risulta torni ancora utile indicargli di compilare con tre processi. Dichiara la variabile CONCURRENCY_LEVEL prima di lanciare il make con questo comando:export CONCURRENCY_LEVEL=3Con scheduler standard impostarla pari al numero di core + 1, mentre con lo scheduler BFS basta impostarla pari al numero di core.
Ma ogni volta che rinstallo il kernel (make install_modules e make install per intendere) devo eliminare quello precedente della stessa versione o viene automaticamente sovrascritto?
Se si sta reinstallando lo stesso kernel tutti i file presenti saranno sostituiti.
ATTENZIONE: in caso di rimozione di moduli nelle compilazioni successive questi non verranno eliminati.
L'install coinvolge questi file:

vmlinuz-x.y.zz-rev: installata in /boot, immagine compressa; creazione backup vmlinuz-x.y.zz-rev.old se già presente
config-x.y.zz-rev: installata in /boot, configurazione, cioè il .config utilizzato; creazione backup config-x.y.zz-rev.old se già presente
System.map-x.y.zz-rev: installata in /boot, mappa dei simboli del kernel (http://rlworkman.net/system.map/); creazione backup System.map-x.y.zz-rev.old se già presente

il modules_install crea o sovrascrive (non distruttivamente) questa cartella:

/lib/modules/x.y.zz-rev/: cartella che contiene i moduli
Installando con il metodo classico:

dovrai lanciare sudo update-grub per forzare il riconoscimento del nuovo kernel, controllare se viene riconosciuto e se il risultato è buono
dovrai ricordarti di rimuovere la cartella dei moduli prima di reinstallare (in caso di ricompilazione con riduzione del numero di moduli)
per disinstallare dovrai rimuovere tutti questi file/cartelle e rilanciare sudo update-grub
Creando i .deb ti basterà installarli e disinstallarli.
Precisamente per creare un .deb come dovrei muovermi una volta compilato il kernel?Non si tratta di creare un .deb dopo: l'intero processo di compilazione è incapsulato.
Non posso scriverlo meglio che sulla guida Ubuntu ufficiale (https://help.ubuntu.com/community/Kernel/Compile#Alternate Build Method: The Old-Fashioned Debian Way) (non ho mai provato make localmodconfig e nemmeno ne ricordavo l'esistenza).

[Emalele1688]

Aspetta, io non sto compilando il kernel di Ubuntu, ma il Kernel Vanilla (scaricato da www.kernel.org, versione 2.6.36.2) con applicata la patch BFS.

Cosa intendi per impostare lo scheduler standard e lo scheduler BFS ?? E' sempre nella configurazione?

[Gimli[2BV!2B]]

Aspetta, io non sto compilando il kernel di Ubuntu, ma il Kernel Vanilla (scaricato da www.kernel.org, versione 2.6.36.2) con applicata la patch BFS.Sì, lo so: a livello pratico non cambia praticamente nulla.
Della sezione che ho linkato (https://help.ubuntu.com/community/Kernel/Compile#Alternate Build Method: The Old-Fashioned Debian Way) devi scartare i primi tre comandi.
Ti evidenzio anche la sezione che riporta le dipendenze necessarie. (https://help.ubuntu.com/community/Kernel/Compile#Tools you'll need)Cosa intendi per impostare lo scheduler standard e lo scheduler BFS ?? E' sempre nella configurazione?Una volta applicata la patch spunteranno un paio di voci nuove nel kernel.
Come ti avevo accennato precedentemente (http://www.hwupgrade.it/forum/showpost.php?p=34070497&postcount=16), ma ho dimenticato di ribadire all'ultimo giro, dai un make oldconfig subito dopo aver applicato la patch BFS.

Quando avrai compilato, installato e cominciato ad utilizzare un kernel dotato di scheduler BFS potrai impostare il CONCURRENCY_LEVEL a 2.

[ezln]

Ciao.
Ho seguito con interesse il thread; in passato mi davo pure io alla compilazione selvaggia....bei tempi:O ...ora non più. Certo che sei un professore della madonna, Gimli :ave: :ave: :ave: ....da dove sei uscito, da un terminale unix?!:D Che distro usi, così, per pura curiosità?

Auguri di buon anno a tutti e buona compilazione ad Emalele!:)

[Gimli[2BV!2B]]

Ma dai ezln, non esagerare và!
Compilare kernel è abbastanza meccanico una volta capito il percorso da seguire.

Sono stato anch'io tentato di lasciar perdere la compilazione dopo un confronto diretto con il kernel Ubuntu, visto che non erano praticamente misurabili vantaggi in uso quotidiano. Poi ho provato la patch che è un po' il leitmotiv di questo thread, il BFS, ed ho riscontrato miglioramenti che mi hanno incoraggiato a continuare.
Le mie distribuzioni? Prima scelta Debian Sid, da qualche mese uso molto Gentoo.

[Emalele1688]

ezln ha perfettamente ragione, Gimli sei un grande, beato te che conosci tutte queste cose, avrai fatto sicuramente molta esperienza :) :) hai tutto il mio rispetto ;)

Dopo numerosi tentativi e kernel panic vari oggi grazie a Gimli ho compilato il mio primo kernel funzionante.
In passato ricordo di aver eliminato il driver video nouveau per far spazio ai driver NVIDIA proprietari, infatti con il nuovo kernel non si avviava X. Entrava in tty1;
Ho scaricato dal sito NVIDIA i driver, e da tty1 l'ho installati sul nuovo kernel, ora pare che va...
Come da te detto infatti ho creato il .deb dando un:
fakeroot make-kpkg --initrd --append-to-version=-some-string-here kernel-image kernel-headers

Che mi ha generato due deb:
Linux image e Linux headers;
Se non sbaglio il primo sono i moduli vero? Il secondo?

Ho altre due domande se hai tempo chiaramente:D
1- Per vedere se la patch BFS è attiva come faccio?
2- E' normale che nella directory modules (/lib/modules) la directory dei moduli del kernel di ubuntu (non da me compilato) ha una grandezza di 118 Megabyte, contro la directory dei moduli del kernel compilato da me è solo 35 Megabyte?

Per quanto riguarda "export CONCURRENCY_LEVEL=3" un grazie infinito, la compilazione del kernel è avvenuta in un tempo brevissimo rispetto a prima:D :D Se il BFS è attivo provvederò a portare il CONCURRENCY_LEVEL a 2 ...

[Gimli[2BV!2B]]

Prego, sono contento di averti accompagnato fino ad un prodotto funzionante :)

Che mi ha generato due deb:
Linux image e Linux headers;
Se non sbaglio il primo sono i moduli vero? Il secondo?
linux-image contiene tutti i componenti del kernel, dalla vmlinuz ai moduli.
linux-headers contiene tutti gli headers, in soldoni si tratta dei file contenenti le informazioni necessarie per compilare software che comunica direttamente col kernel (come driver aggiuntivi). Se hai nozioni di C, si tratta dei file *.h che contengono i prototipi delle funzioni esposte.
Per vedere se la patch BFS è attiva come faccio?Dal mio config:kwankey ~# grep BFS /boot/config-$(uname -r)
CONFIG_SCHED_BFS=y
# CONFIG_HUGETLBFS is not set
E' normale che nella directory modules (/lib/modules) la directory dei moduli del kernel di ubuntu (non da me compilato) ha una grandezza di 118 Megabyte, contro la directory dei moduli del kernel compilato da me è solo 35 Megabyte?È una differenza piuttosto marcata.
Hai solo fatto make oldconfig o hai cominciato a fare un po' di pulizia, disattivando roba che non ti serve?
Altra possibilità è che tu abbia attivato General setup -> Optimize for size che non credo sia abilitato in Ubuntu (non ho controllato, vado a memoria).
Nel caso fosse attivo ti consiglierei di disattivarlo, il tuo AMD non ha cache piccole come i vecchi Athlon XP.

[Emalele1688]

Allora ancora non ho iniziato con le ottimizzazioni e le varie pulizie del kernel; Fino ad ora do solo make oldconfig e lascio il tasto invio premuto assicurandomi che la prima voce (quella che mi chiede se attivare il BFS) sia impostata su Y. :D

Ho notato un piccolo accorgimento in fase di boot, subito dopo il menu Grub, quando seleziono il boot con il Kernel da me compilato;
Mi escono le seguenti scritte:
Powernow-k8 limiting to CPU failed
ata1 softreset faild (device not ready)
ata3 softreset faild (device not ready)

Quel Powernow-k8 limiting to CPU failed non mi convince tanto, sto facendo delle ricerche su internet :mbe:

Un altra cosa già che ci sono: sai come posso rimuovere il kernel image precedentemente da me compilato e non funzionante? Mi è rimasto nel menu Grub insieme alla sua configurazione old; Gli ho solo rimosso manualmente la directory /lib/modules/2.6.36.2-generic, che altro devo eliminare?

[Gimli[2BV!2B]]

powernow-k8: limiting to cpu %u failedDa quel che ho trovato potrebbe riguardare un riconoscimento imperfetto delle funzionalità energetiche avanzate dalla CPU: hai attiva la variazione automatica delle frequenze (PowerNow!)? Riscontri effettive variazioni durante l'utilizzo del pc?watch -d 'cat /proc/cpuinfo | grep MHz'
Potrebbe anche essere un tentativo di inizializzazione del Turbo Core, di cui la tua cpu mi risulta sprovvista.
ata1: Softreset failed (Device not ready)Questo sembra essere un messaggio molto comune, credo sia riscontrato solo da possessori di cpu AMD.
Hai il southbridge ATI SB600? In questo caso il messaggio verrà sempre fuori, ma poi la funzione che lo sputa viene rilanciata con i parametri corretti per aggirare il comportamento fuori standard della periferica.
Se non hai quel controller non darei comunque troppo peso a quel messaggio, a meno che non rallenti sensibilmente l'avvio.

In caso di messaggi sospetti la prima domanda a cui cerco risposta è: si osservano anche con il kernel della distribuzione?
Naturalmente Ubuntu normalmente non li mostra, ma sono tranquillamente consultabili tramite comando dmesg (tutti i messaggi del kernel dall'ultimo boot) e nei log /var/log/dmesg, /var/log/dmesg.0, /var/log/dmesg.N.gz, /var/log/kern.log, ecc...
Se non li presenta è opportuno controllare se ci sono novità nella sezione del kernel coinvolto: se gli errori fossero bloccanti potrebbe risultare necessario utilizzare una versione precedente (o aggiornata se si fosse rimasti indietro).
Altrimenti si cercano informazioni in giro, al solito.

Un altra cosa già che ci sono: sai come posso rimuovere il kernel image precedentemente da me compilato e non funzionante? Mi è rimasto nel menu Grub insieme alla sua configurazione old; Gli ho solo rimosso manualmente la directory /lib/modules/2.6.36.2-generic, che altro devo eliminare?
Se non hai usato i .deb devi rimuovere anche tutti i tris di file obsoleti (http://www.hwupgrade.it/forum/showpost.php?p=34083119&postcount=22) da /boot, poi dare un sudo update-grub
Se hai usato i .deb "dimenticati" dell'esistenza dei file e disinstalla i pacchetti.

[Emalele1688]

Dunque ho controllato le frequenze dei due core come da te detto (watch -d 'cat /proc/cpuinfo | grep MHz');
Diciamo che mi era preso un colpo quando ho letto 1000.00 MHz per ogni core :eek: :eek: Ma poi mi sono ricordato dell'esistenza del Cool n Quiet di AMD che da BIOS era abilitato... Disabilitandolo le frequenze sono tornate ok, e trai messaggi del kernel al boot è apparsa una voce che mi chiede di aggiornare il BIOS, non ricordo ora cosa c'era scritto precisamente; Fatto che il BIOS l'ho aggiornato usando flashrom, ed i messaggi del Kernel sono rimasti, compreso quello che mi chiede di aggiornare il BIOS :confused:

In ogni caso ho una speranza:
Dando un make gconfig per la configurazione del Kernel ho trovato questa opzione nell'albero Processor type and features:
Processor type and features -> CPU Frequency scaling -> AMD Opteron/Athlon64 PowerNow
Se disabilito AMD Opteron/Athlon64 PowerNow si potrebbe risolvere secondo te?
Anzi, siccome la gestione delle frequenze della CPU durante l'uso del sistema non mi interessa (o meglio se proprio devo preferisco il classico Overclock) posso tentare a disabilitare l'intero sottoalbero CPU Frequency scaling o sai già a priori che farò danno?

[Gimli[2BV!2B]]

Hai provato a fare qualche lavoro per caricare i core?
Non devi disabilitare il PowerNow! se abbassa correttamente le frequenze quando il sistema è a riposo, è un'ottima invenzione!

Stesso discorso per il driver relativo nel kernel.

[Emalele1688]

Hai ragione non disabiliterò il PowerNow, solo non riesco a capire se sta entrando in funzione o meno ...

Sto cercando di fare dei Benchmark con phoronix test suite; sto installando diversi tipi di bench dal database di phoronix da testare sui diversi Kernel (precompilato di ubuntu senza BFS versus compilato vanilla con BFS);
Appena avrò dei risultati ragionevoli li posto ...

Ho riabilitato l'AMD Cool n Quiet, ho notato che a riposo i due core sono a 1 GHz circa di frequenza, solo sotto stress toccano il limite di 2.4 GHz.
Dunque le frequenze sembrano ok, variano durante l'uso del sistema in modo moderato ...
Allora a cosa si riferisce quel: "powernow-k8: limiting to cpu failed" ?? Sto continuando a cercare ed a smanettare, vediamo cosa ne ricaviamo ...

[Pardo]

L'importante e` che variano le frequenze, non c'e` altro. Non c'e` bisogno di disabilitare niente anche se durante un lavoro ti tira il culo e vuoi settare il massimo fai cpufreq-set -g performance e ciao. Giusto perche` comunque in effetti con la cpu che gira sempre al minimo un po' di latenza in alcune cose si puo` notare. E` anche possibile elevare il "minimo" a qualcosa di piu` se magari vedi che a 1 GHz il desktop e` poco responsive.

[Emalele1688]

Io ora sto provando l'applet di gnome "Variazione frequenza CPU" ed a seconda dell'uso che ne faccio del PC imposto su "Performance" o "Ondemand" oppure anche "Powersave" se proprio non faccio nulla ... In ogni caso cambia la frequenza della CPU in un range che parte da 1 GHz fino a 2.4 GHz .. Ma funziona sul serio questa applet?? Posso farne affidabilità secondo voi?

Ho eseguito tre tipi diversi di Benchmark sui kernel Vanilla 2.6.36.2 + patch BFS, da me compilato, e kernel ubuntu 2.6.35.24-generic;
I benchmark eseguiti con Phoronix test suite sono i seguenti:
-BZIP2 compression
-FFmpeg audio/video encoding
-Build Linux Kernel

I risultati ottenuti dai due Kernel sono più o meno alla pari, vorrei postare i 4 grafici (.png) ma il forum non me lo permette.. In ogni caso ricompilerò il Kernel iniziando con qualche piccola ottimizzazione e alleggerimento dei vari moduli, quindi farò altri benchmark ...

Per il messaggio del "powernow-k8: limiting to cpu failed" ho trovato sul sito di AMD il driver PowerNow per processori AMD Athlon X2 da includere nel Kernel (sono due sorgenti: il file header powernow-k8.h e la sorgente powernow-k8.c);
Peccato però che chiaramente nel Kernel 2.6.36.2 tali sorgenti sono già incluse... Quindi penso che non risolverò così la cosa ...
Può darsi che quel messaggio alla fine non sia nulla di grave? Insomma le frequenze sembrano ok!
Provo a vedere se il messaggio esce anche con il kernel generic di Ubuntu, vediamo un pò..
Per fare ciò devo dare dmesg giusto ?

[Gimli[2BV!2B]]

L'applet di Gnome funziona correttamente; personalmente ho messo ondemand come default e non me ne sono più curato.

Riguardo ai benchmark direi che è corretto che i risultati risultino pressoché uguali a seguito di una semplice ricompilata + patch BFS.
Quella patch introduce miglioramenti difficilmente misurabili con benchmark classici, essenzialmente una maggiore prontezza del sistema durante l'uso interattivo.

Per finire, l'errore: se la frequenza varia correttamente non mi preoccuperei granché di quel messaggio.
Puoi dare un dmesg avviando con il kernel Ubuntu per controllare se è presente.
Hai provato ad aggiornare al nuovo 2.6.37? Magari ora han corretto il problema.

[Emalele1688]

Ho ricompilato il kernel con la sorgente 2.6.37, è filato tutto liscio fortunatamente, ho iniziato anche con qualche ottimizzazione sul gconfig :D
Il messaggio all'avvio si continua a presentare, ma le frequenze però sono ok ..
Dando un "dmesg | grep powernow" sul kernel 2.6.35.24 di Ubuntu l'errore non c'è, quindi lo vede solo il kernel da me compilato ... Però se in realtà tutto funziona per ora posso lasciar stare, più avanti si vedrà :) :)

Conoscete magari un modo per togliere quei maledetti messaggi di errore del Kernel in fase di boot?

Un'altra cosa :D Io generalmente quando compilo un programma con gcc / g++ passo al compilatore alcuni flag per l'ottimizzazione (-O2, -O3, -march=Athlon64, -pipe, -m3dnow ecc...);
Nel caso della configurazione del Kernel mi sembra di aver capito che questi passaggi non si eseguono poichè i moduli 3dnow, msse2, mmx ecc sono già abilitati sul .config.. Vero?
In ogni caso ora inizierò a smanettare di brutto nella configurazione, vediamo quanti casini combino:D :D

[Gimli[2BV!2B]]

Conoscete magari un modo per togliere quei maledetti messaggi di errore del Kernel in fase di boot?Non ricordo con quale importanza erano classificati.
Se si tratta di errori non c'è modo di mascherarli, tranne commentandoli dai sorgenti o utilizzando uno splash screen.
Se si tratta di warning dovrebbero sparire insieme a tutti gli altri messaggi utilizzando passando il parametro quiet al kernel, in Grub.

Io generalmente quando compilo un programma con gcc / g++ passo al compilatore alcuni flag per l'ottimizzazione (-O2, -O3, -march=Athlon64, -pipe, -m3dnow ecc...);Naturalmente si cerca di ottenere il meglio.
Per attivare le ottimizzazioni corrette per la propria CPU e le ottimizzazioni classiche (-O2 -fomit-frame-pointer e altre piccolezze) occorre impostare queste voci ([ ] evidenzia opzioni da disattivare):General setup --->
[ ] Optimize for size
Optimize trace point call sites

Processor type and features --->
[ ] Support for extended (non-PC) x86 platforms
Single-depth WCHAN output
Processor family (SCEGLIERE LA FAMIGLIA CORRETTA) --->
[ ] Generic x86 support

Kernel hacking --->
[ ] Compile the kernel with frame pointers
Allow gcc to uninline functions marked 'inline'

Ricorda di fare backup delle configurazioni buone!

[Emalele1688]

Aspetta, fammi capire, che io sappia la splash screen è la schermata visualizzata in fase di caricamento di un programma ...
Quindi nel momento che visualizzo i messaggi sul monitor il sistema non è fermo? Carica?
Dunque non perdo tempo di boot ... Se così fosse i messaggi possono anche restare ....

[Gimli[2BV!2B]]

Con "splash screen" volevo indicare la grafica standard di Ubuntu visualizzata durante l'avvio. Se non sbaglio la denominazione più calzante è boot splash.Quindi nel momento che visualizzo i messaggi sul monitor il sistema non è fermo? Carica?Sì, lui sta continuando a fare il suo mestiere.
In alcuni casi però cercherà di sistemare il problema individuato impiegando tempi percepibili.

Da qualche tempo nei kernel della famiglia Debian è stata attivata la stampa dell'istante in cui viene visualizzato il messaggio (Kernel hacking ---> Show timing information on printks).
Ricercando in dmesg gli/l'errore e controllando i tempi delle righe successive è possibile capire se si hanno ritardi fastidiosi.

[Emalele1688]

Allora, ti posto l'output di dmesg a due messaggi prima del problema powernow e 5 messaggi dopo ... mi sembra di intuire che i valori a sinistra è il tempo impiegato tra un operazione e l'altra ... Giusto? Se così fosse stiamo parlando di millesimi di secondi ....

0.947324] NET: Registered protocol family 17
[ 0.947345] Registering the dns_resolver key type
[ 0.947368] powernow-k8: Found 1 AMD Athlon(tm) 64 X2 Dual Core Processor 4600+ (2 cpu cores) (version 2.20.00)
[ 0.947414] powernow-k8: 0 : fid 0x10 (2400 MHz), vid 0xa
[ 0.947416] powernow-k8: 1 : fid 0xe (2200 MHz), vid 0xc
[ 0.947418] powernow-k8: 2 : fid 0xc (2000 MHz), vid 0xe
[ 0.947420] powernow-k8: 3 : fid 0xa (1800 MHz), vid 0x10
[ 0.947422] powernow-k8: 4 : fid 0x2 (1000 MHz), vid 0x12
[ 0.947447] powernow-k8: limiting to cpu 0 failed
[ 0.947493] powernow-k8: limiting to cpu 0 failed
[ 0.947638] PM: Hibernation image not present or could not be loaded.
[ 0.947649] registered taskstats version 1
[ 0.947941] Magic number: 11:728:451
[ 0.948063] rtc_cmos 00:02: setting system clock to 2011-01-14 22:24:15 UTC (1295043855)
[ 0.948066] BIOS EDD facility v0.16 2004-Jun-25, 0 devices found

[Gimli[2BV!2B]]

Esatto, a sinistra hai il tempo in secondi trascorso dal caricamento del kernel in memoria: passano 2 decimi di millesimo di secondo abbondanti a cavallo degli errori, direi che è trascurabile :D

[ezln]

;34178404']Non ricordo con quale importanza erano classificati.
Se si tratta di errori non c'è modo di mascherarli, tranne commentandoli dai sorgenti o utilizzando uno splash screen.
Se si tratta di warning dovrebbero sparire insieme a tutti gli altri messaggi utilizzando passando il parametro quiet al kernel, in Grub.

Naturalmente si cerca di ottenere il meglio.
Per attivare le ottimizzazioni corrette per la propria CPU e le ottimizzazioni classiche (-O2 -fomit-frame-pointer e altre piccolezze) occorre impostare queste voci ([ ] evidenzia opzioni da disattivare):General setup --->
[ ] Optimize for size
Optimize trace point call sites

Processor type and features --->
[ ] Support for extended (non-PC) x86 platforms
Single-depth WCHAN output
Processor family (SCEGLIERE LA FAMIGLIA CORRETTA) --->
[ ] Generic x86 support

Kernel hacking --->
[ ] Compile the kernel with frame pointers
Allow gcc to uninline functions marked 'inline'

Ricorda di fare backup delle configurazioni buone!

Ciao.
A parte i soliti complimenti a Gimli, un drago da spavento, e pure ad Emalele perchè non demorde e impara a vista d'occhio, volevo chiedere una cosa: nel quote, Gimli, dici "...attivare le ottimizzazioni corrette per la propria CPU e le ottimizzazioni classiche (-O2 -fomit-frame-pointer e altre piccolezze) occorre impostare queste voci...etc etc"; se io poi su una gentoo imposto determinate CFLAGS in make.conf -ad esempio non mi interessa il -fomit-frame-pointer- e nel kernel sono abilitate le opzioni di cui parli, che accade? Il compilatore come si comporta?
Boh magari è una domanda stupida...:confused:

[Gimli[2BV!2B]]

@ezln le impostazioni del kernel vincono.
La compilazione del cuore del sistema offre meno possibilità di personalizzazione sotto questo punto di vista ed è basata sulle impostazioni del .config.
Ad esempio non è possibile impostare un O3 (senza modificare manualmente gli script), perché non è assolutamente certo che le ottimizzazioni aggiuntive permettano di ottenere un kernel avviabile, anzi è quasi certo il contrario.

Il make.conf vale solo per gli strumenti della distribuzione: portage, ebuild, ecc...

[ezln]

;34187702']@ezln le impostazioni del kernel vincono.
La compilazione del cuore del sistema offre meno possibilità di personalizzazione sotto questo punto di vista ed è basata sulle impostazioni del .config.
Ad esempio non è possibile impostare un O3 (senza modificare manualmente gli script), perché non è assolutamente certo che le ottimizzazioni aggiuntive permettano di ottenere un kernel avviabile, anzi è quasi certo il contrario.

Il make.conf vale solo per gli strumenti della distribuzione: portage, ebuild, ecc...

Grazie! Ricevuto e capito. Chiaro come sempre, Gimli. LOL:)

[jeremy.83]

Mi spiace sporcare il thread, ma mi aggrego ai complimenti a Gimli, è uno dei migliori utenti attivi al momento sul forum, tanto di cappello

:ave: :ave: :ave:

[darkbasic]

;34187702']@ezlnAd esempio non è possibile impostare un O3 (senza modificare manualmente gli script), perché non è assolutamente certo che le ottimizzazioni aggiuntive permettano di ottenere un kernel avviabile, anzi è quasi certo il contrario.

Compila compila, dovresti vedere le ottimizzazioni assurde che usano i ragazzi di linuxdna con il compilatore icc :D
Se sei interessato alle performance quello è il kernel più veloce che puoi ottenere, ma è talmente tanto infarcito di bug che io ho lasciato perdere (sono perfino tornato alla toolchain di stable :doh: )

[Gimli[2BV!2B]]

Grazie jeremy.83 :)

@darkbasic è vero, ricordo di averne letto. Avevo pure avuto voglia di provarlo, naturalmente, ma l'AMD Athlon XP che avevo è stato lo scoglio che non mi ha nemmeno fatto partire (dovevo usare un'icc discretamente vecchio per problemi SSE e applicare le patch al compilato per far funzionare il codice ottimizzato).
Ci credo che sia ingestibile, già molti programmi normali si rompono con icc, immagino il kernel.

Ho fatto un giro ora sul sito (ora ho un Pentium IV :asd:). Hanno rinominato d'ufficio l'amd64 in intel64? Mi sembra di capire che il progetto sia un po' in stallo al momento.

[darkbasic]

Sì è un po in stallo effettivamente...

[Emalele1688]

LinuxDNA cosa sarebbe? (Per curiosità)
Mi sembra di capire che sia un progetto riguardante l'ottimizzazione del Kernel e la compilazione di questo con il compilatore Intel ...

[Gimli[2BV!2B]]

LinuxDNA (http://www.linuxdna.com/) è (stato?) un progetto per rendere il kernel Linux compilabile utilizzando il compilatore proprietario Intel icc.
Per raggiungere l'obiettivo hanno dovuto modificare discretamente il makefile, oltre ad andare incontro a svariati errori dovuti al fatto che i sorgenti sono stati scritti per gcc (icc e gcc son due bestie completamente diverse).

I compilatori Intel hanno la fama di essere tra i più efficienti (10÷40%), oltre ad essere noti per produrre codice che si comporta in modo diverso a seconda della cpu che lo esegue (http://en.wikipedia.org/wiki/Intel_C%2B%2B_Compiler#Criticism).
Se la cpu è Intel viene eseguito il codice ottimizzato con le estensioni Intel (dalle SSE in avanti), altrimenti viene usato quello normale.
Questo anche se la cpu dichiara di supportare queste istruzioni: si tratta di un semplice test sul nome del produttore.

Se si vogliono eseguire decentemente i binari prodotti con icc su macchine non Intel occorre patchare o i binari generati o i binari del compilatore stesso per produrre direttamente programmi buoni (http://www.swallowtail.org/naughty-intel.shtml) (patchando il compilatore si va contro la sua EULA).

Tirando le somme: il compilatore Intel può essere definito lo stato dell'arte dei compilatori, però contiene limitazioni enormemente discutibili e praticamente tutto il codice open source è stato scritto per gcc.

[niki89]

ciao ragazzi io ho un portatile con i3 330M con ati 5650 una volta aggiornai il kernel però mi ritrovai con i driver non compatibili.
C'e un modo per raggirare questa cosa?

[Gimli[2BV!2B]]

Cosa vuol dire "driver non compatibili"?
Periferiche che non funzionavano?
Kernel panic all'avvio?

Che distribuzione?
Ma, soprattutto, kernel di distribuzione o compilato? Tu scrivi un generico "aggiornamento".

[Emalele1688]

Una perplessità che mi è giunta in mente, forse anche stupida...
Ma se io compilo un Kernel vanilla usando il file .config del Kernel Ubuntu; Per intenderci compilo il Kernel vanilla 2.6.37 ed all'interno dei sorgenti inserisco il .config proveniente dall'ultimo kernel di Ubuntu 10.10 (dovrebbe essere il 2.6.35.24), una volta che do "make oldconfig", poichè compilo un kernel vanilla le voci di configurazione appartenenti solamente al Kernel di Ubuntu (Tutto ciò che è stato aggiunto dagli sviluppatori di Ubuntu nel Kernel) vengono automaticamente rimosse ??

[Gimli[2BV!2B]]

Tutte le opzioni che non hanno corrispondenza vengono rimosse e tutte le novità vengono proposte.

Il make oldconfig parte dalle opzioni disponibili nei sorgenti e imposta i valori che trova nel .config, dopodiché chiede che fare con le opzioni che non hanno ricevuto un valore.
Una volta raccolti tutti i parametri sovrascrive il .config

[*andre*]

ciao ragazzi
uppo la discussione per avere un chiarimento.. stavo compilando l'ultima versione del kernel(2.6.37) però mi è finito lo spazio sul disco :doh:

la situazione della partizione root è questa (http://i56.tinypic.com/18dqnp.png)
cioè ho lasciato 15GB..

è possibile che mi tenga più di 5 GB la versione compilata? (compresso il source code pesa 70mb...)

poi una cosa non mi torna.. li mi segnala la partizione home piena.. ma la home la ho montata in un'altra partizione da 50 GB :rolleyes: :rolleyes:

consigli?

[Gimli[2BV!2B]]

@*andre*, anche il kernel più completo non penso possa occupare più di 1÷1,5 GiB:kwankey ~# du -sh /usr/src/linux-2.6.37-ck
579M /usr/src/linux-2.6.37-ck

Riguardo alla segnalazione sulla /home posso solo dirti che in Kde non ho mai avuto messaggi errati...

Che dice df -h ?

[darkbasic]

Confermo gli 1.5 GB

[*andre*]

;34263091']@*andre*, anche il kernel più completo non penso possa occupare più di 1÷1,5 GiB:kwankey ~# du -sh /usr/src/linux-2.6.37-ck
579M /usr/src/linux-2.6.37-ck

Riguardo alla segnalazione sulla /home posso solo dirti che in Kde non ho mai avuto messaggi errati...

Che dice df -h ?

Confermo gli 1.5 GB

Grazie per le risposte..
"du -sh" come nel tuo tag code mi dava 5GB :sofico:
invece df -h:
andrea@andrea-Mint ~ $ df -h
File system Dim. Usati Disp. Uso% Montato su
/dev/sda5 11G 4,3G 5,3G 45% /
none 2,0G 328K 2,0G 1% /dev
none 2,0G 656K 2,0G 1% /dev/shm
none 2,0G 316K 2,0G 1% /var/run
none 2,0G 0 2,0G 0% /var/lock
/dev/sda6 46G 5,5G 38G 13% /home


adesso l'ho liberato un pò visto che restavano 15mb liberi :doh:

ho fatto la prova sia con kernel vanilla (2.6.37) sia con l'ultima versione per Mint 10 (2.6.35-24) ma niente.. sicuro che sono io che sbaglio qualcosa, ma oltre a esermi letto tutta questa discussione mi sono documentato su debianizzati..
Questi sono i passi che ho fatto l'ultima volta con il kernel della distribuzione:

Scarico con apt l'ultimo kernel in .deb
vado in /usr/src/LinuxYYZZ
ci copio la patch bfs e la applico con il comado in prima pagina:
patch -d linux-2.6.35-24 -p1 < 2.6.35-10-sched-bfs-363.patch
copio la configurazione da /boot/
make oldconfig , in cui la unica diferenza che mi indica è lo scheduler bfs e un'altra cosa (sarà la differenza tra la versione di kernel che ho ora (2.6.35-22) con la 2.6.35-24 disponibile nei repository
da make menuconfig tolgo solo l'initrd e compilo i driver ext3-4
dopo visto che vorrei un .deb lancio:
CONCURRENCY_LEVEL=3 fakeroot make-kpkg --append-to-version -"nomepersonalizzato" --revision=1 kernel_image kernel_headers


:help:

[Gimli[2BV!2B]]

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

Per il resto l'unico punto che non mi torna è il 6:da make menuconfig tolgo solo l'initrd e compilo i driver ext3-4Devi 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 CORRETTOPer individuare velocemente qual'è il driver in uso con il kernel ufficiale puoi usare lspci -k

[*andre*]

;34272685']Mah, 5 GiB mi sembran proprio troppi. AMD64, per caso?

Per il resto l'unico punto che non mi torna è il 6:Devi 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 CORRETTOPer 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]]

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*]

;34273592']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 (:rolleyes: )

[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... :rolleyes:

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

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]]

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.

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è :D ). 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 :D

Comunque molto meglio distcc :D

[Dane]

Chromium + icedtea + openoffice = ci rivediamo fra tre giorni :D

Comunque molto meglio distcc :D

ricordandosi di mettere un -j20 con i processori odierni :D

quotone per i il "trittico" citato :D

[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).

ricordandosi di mettere un -j20 con i processori odierniOrcocà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)

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 :asd:
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]

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) :D

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 :asd:
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]

;34284964']11 ore ed è fatta (PIV 2.2GHz).
Bazzeccole :D
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 ;)

;34284964']Ho letto pareri discordanti a riguardo e molti bug in cui si consigliava di ricompilare disattivandola.
Infatti, i problemi sono già abbastanza senza...

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

Specie quando l'aiutino viene da uno di questi :sofico:

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]

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 :oink:

[Dane]

No, è proprio una flag attiva di default ora :oink:

pardon :D

cmq ti credo che con quella roba viaggia più distcc :eek:

[Gimli[2BV!2B]]

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

[darkbasic]

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

[Dane]

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

solo un ssd? :ciapet:

[Gimli[2BV!2B]]

Confermo che io ci metto più tempo a scaricare i sorgenti :)

Prima o poi anch'io sarò costretto ad usare queste diavolerie moderne... multi-core, 64bit, più di un giga di RAM, SSD.
Il fatto è che quando sono a casa perdo solo tempo su internet e non sento la necessità di uscire dallo scorso millennio...

[darkbasic]

Quello è il mio server, il fisso è l'Athlon64 che vedi in firma (mentre il portatile un Core2 Duo Ultra Low Voltage a 1.4Ghz).
Come vedi sono rimasto fermo a 8 anni fa anch'io :stordita:

[Emalele1688]

Scusate se risbuco dal nulla:D

Ma che cosa sono CCACHE e DISTCC ??

Purtroppo essendo ancora studente in materia ho dedicato solo interi anni ad imparare a programmare il linguaggio c/c++, e meno alle varie tecnologie che esistono e che pian piano grazie a voi conosco :) :)

[Dane]

ccache è un software che mette in cache le cose già compilate per (eventualmente) riutilizzarle quando si ricompilano le stesse cose.

distcc è un software che fa compilare anche (o solo) ad altri pc in rete. Devi avere lo stessa versione del compilatore. Ci puoi anche crosscompilare.

[Emalele1688]

Sembrano entrambi molto interessanti :D :D Vedrò qualche documentazione...
Scusate se vi scoccio ancora con le patch del kernel; Conoscete, o per lo meno esiste qualche patch per il fast boot?

[Gimli[2BV!2B]]

Io non conosco patch che siano indirizzate specificamente a questo scopo.

Il fatto è che è possibile ottenere tempi di boot di qualche secondo, ma la porzione di questo tempo costituita dall'avvio del kernel è di circa un ordine di grandezza (o più) inferiore rispetto a quello dei demoni che vengono lanciati automaticamente.

È quindi possibile trovare piccole patch che possono alleggerire appena il kernel (qualcuna l'ho incontrata spulciando la grossa patch Ubuntu), ma si tratta di modifiche assolutamente eterogenee e molto mutevoli (spesso sono piccole correzioni che vengono estratte da nuove versioni) il cui impatto è solitamente quasi trascurabile.

Qui puoi trovare un approfondimento scritto un paio di anni fa che permette di farsi un'idea dei punti su cui si può agire. (http://lwn.net/Articles/299483/)

[darkbasic]

Piuttosto usa un sistema di init decente :)

[Emalele1688]

Allora:
Da quel che so Ubuntu 10.10 dovrebbe usare per default il sistema init Upstart;
Correggetemi sempre se sbaglio ....
Con il kernel vanilla da me compilato rimane l'init Upstart ?? O il nuovo kernel, non essendo quello ottimizzato per Ubuntu ne utilizza un'altro ??
Si possono configurare gli init in Ubuntu ??

[Gimli[2BV!2B]]

L'init è sempre quello, si tratta di un programma a parte, il primo invocato automaticamente dal kernel una volta che ha terminato di inizializzare il sistema.

Io non mi sono mai messo lì a provare un init diverso dal quello della distribuzione e non sono molto informato sull'argomento.

L'Upstart di Ubuntu non mi piace perché ancora incompleto:

sudo restart gdm mentre sudo /etc/init.d/networking restart, per esempio
c'è modo di disattivare un demone senza disinstallarlo o fare modifiche eterogenee nei singoli specifici file di configurazione?


Non ho idea di quale init possa offrire vantaggi sull'Upstart che hai già.
L'unico che conosco come in parte stabile è initNG (http://initng.sourceforge.net/trac), ma apparentemente Upstart fornisce già le principali funzionalità che offre (https://help.ubuntu.com/community/InitNG).

darkbasic, tu hai fatto qualche sperimentazione interessante?

[darkbasic]

;34384893']darkbasic, tu hai fatto qualche sperimentazione interessante?

Ho provato initng a suo tempo, ma adesso l'alternativa più interessante sempre essere systemd. Non è ancora completamente maturo, ma verrà utilizzato nelle prossime release di fedora e opensuse. La mia opinione al riguardo? Se non si usa una distro from scratch, lasciate la gestione dell'init ai mantainer della distro.

[Gimli[2BV!2B]]

Dalla descrizione questo systemd sembra avere obiettivi interessanti (non solo la solita parallelizzazione massiva) e voler utilizzare varie funzionalità del kernel per svolgere questi compiti, senza avere la necessità di reinventare la ruota.
I file di configurazione hanno un aspetto compatto ed elegante, mi piace ancora di più.

Grazie della segnalazione!

[darkbasic]

;34385093']non solo la solita parallelizzazione massiva

E' proprio per questo che non rimarrà un progetto fine a se stesso ma verrà adottato globalmente da un po tutte le distro.
FINALMENTE aggiungerei, sembrava troppo chiedere un sistema di init decente :doh:

[blair]

come ha già detto darkbasic, fedora 15 ha rimpiazzato Upstart con systemd e la percentuale di completamento è del 100%. Nella rawhide già c'è.
Quindi se volete vederlo, testarlo o giocarci un po' con fedora è molto semplice, potente installare in una macchina virtuale fedora 14, e aggiornate a rawhide oppure installare direttamente quella.

[Gimli[2BV!2B]]

Quasi quasi monto un disco nel cassetto vuoto e do un'occhiata a dove è arrivata Fedora. Rimane la distribuzione che non utilizzo verso cui ho maggiore interesse.
Grazie blair!

[darkbasic]

Il problema di fedora è che è troppo bleeding edge, va bene giusto per testare nuove tecnologie per red hat enterprise.

[Emalele1688]

Scusate:
Ma la variabile di ambiente CONCURRENCY_LEVEL vale anche per g++ ?

[blair]

La variabile d'ambiente CONCURRENCY_LEVEL serve per settare il numero di jobs da far usare a make (-j)
Viene utilizzata per la compilazione del kernel e altro non fa che questo.
Un modo standard per ottenere lo stesso "effetto" con altri tipi di compilazione è passare direttamente il parametro jobs a make:
Esempio: make -j7

[Emalele1688]

Possibile che compilando le librerie CEGUI, mediamente i 2 Core della CPU erano all'80% ? E la compilazione di tali librerie ha impiegato buoni 20 minuti :eek:

[blair]

è possibile se la libreria è pesante da compilare, però non ho nessun riscontro sui tempi, non usandola non l'ho mai compilata.

[Gimli[2BV!2B]]

Anch'io non l'ho mai usata, ma mi sembra plausibile leggendone una sommaria descrizione.

[Emalele1688]

Scusate: Mi viene spontanea una domanda ... :D :D
Tempo fa ho compilato il Kernel senza includere il modulo OSS (Open Sound System), che credevo non fosse di vitale importanza;
Invece oggi mi sono accorto che ho un'applicazione che ne fa uso, quindi devo integrarlo ...
A prescindere dal fatto che tanto il Kernel lo devo ricompilare con nuove configurazioni, ma se si volesse includere un modulo non esiste alternativa alla ricompilazione?

[Gimli[2BV!2B]]

Riguardo all'OSS, immagino tu ti stia riferendo agli strati di compatibilità contenuti nei driver ALSA, non al vecchio OSS deprecato.

Se hai necessità di aggiungere un opzione e non un modulo, non conosco altro modo che rilanciare la compilazione principale.
Se i sorgenti non sono stati puliti (make clean o mrproper) e non si scatena una modifica che tocca tutti i sorgenti, si dovrà attendere la sola compilazione dei moduli (integrati o no) coinvolti.
Idem se si integra un modulo o si desidera rimuoverne l'integrazione.

Se si aggiunge un modulo, lasciandolo esterno al kernel, ci si può limitare ad un make modules && make modules_install
Solitamente si avrà la compilazione dei soli nuovi moduli (sempre se non si è fatto un clean), reinstallandoli poi tutti quanti.

Quindi consiglierei semplicemente di evitare di pulire i sorgenti (salvo in caso di limiti di spazio) o si può inserire la citata ccache, ma non conosco altre possibili scorciatoie.

[Emalele1688]

Riguardo OSS, ovviamente, mi riferivo solo alla compatibilità delle applicazioni OSS con ALSA. Credo che molte applicazioni multi piattaforma richiedono tale interfaccia ...
Dunque tanto per sapere il modulo in questione, SE NON ERRO, è snd-seq-oss.ko; Giusto?

Dunque sarebbe (teoricamente) bastato:
make modules snd-seq-oss
make modules_install snd-seq-oss
Giusto ?

Se invece ho bisogno di non caricare un modulo precedentemente integrato all'avvio, basta aggiungerlo alla blacklist?
/etc/modprobe.d/blacklist.conf
Per esempio posso togliere l'integrazione del modulo "neuveau" inserendo la riga
"blacklist nouveau"
sul file /etc/modprobe.d/blacklist.conf ??

[darkbasic]

A dire il vero è possibile compilare solo il modulo incriminato. Non ci ho mai provato, ma temo che sia necessario fare qualche modifica al makefile.

[WarDuck]

Il problema di fedora è che è troppo bleeding edge, va bene giusto per testare nuove tecnologie per red hat enterprise.

Mi sa che non conosci Arch :D.

Tra l'altro molto più stabile di altre distro "a lunga durata".

[Emalele1688]

Arch la sto povando ora:D
L'ho installata su un'altra partizione, molto complessa ma anche molto interessante.

Ma come si integrano nel kernel i moduli compilati ma non integrati?
Basta dare il comando modprobe nome_modulo?
Le blacklist che sono?

[darkbasic]

Mi sa che non conosci Arch :D

Fosse per me non sarebbe un problema (la mia gentoo è bleeding edge da fare schifo) ma non me la sentierei di consigliare distro simili a chi non è avvezzo.

[Emalele1688]

Ma secondo voi può essere che sotto Arch linux la compilazione di un file cpp sia di gran lunga più veloce che sotto Ubuntu??

[darkbasic]

No.

[Emalele1688]

E' la risposta che mi sono dato da solo, evidentemente sarà per la diversa configurazione usata in compilazione ....
Grazie a tutti:)

[pabloski]

beh se lo compili con llvm di sicuro vai più veloce di gcc :D

[Gimli[2BV!2B]]

Vorresti quindi patchare i sorgenti della tua distribuzione con BFS?

Potrebbe funzionare, ma probabilmente le patch non sono compatibili.
È molto probabile che insistano su almeno un file comune, rendendo impossibile l'applicazione di tutte le modifiche da parte dello strumento patch.

Anche in caso di applicazione con successo non è garantito che le modifiche applicate dalla distribuzione siano compatibili con quelle della patch esterna.

Tirando le somme: nessuno ti impedisce di provare ma non te lo consiglierei.

[darkbasic]

Le patch delle varie distribuzioni in genere non vanno a toccare lo scheduler, e anche se lo facessero basterebbe non applicare quella determinata patch. Il punto è che non ne vedo il motivo: i vantaggi di BFS oggigiorno sono risibili e quando servono veramente latenze molto basse l'unica è andare di patchset realtime (fermo al 2.6.33 o a un 2.6.34 accrocchiato :muro: ). La buona notizia è che il ramo -rt sta subendo una grossa riscrittura e tenterà la strada verso il mainline :cool:

[Gimli[2BV!2B]]

Vero, le distribuzioni difficilmente toccano lo scheduler.
Però, per fare un esempio, considero probabile un conflitto nell'applicazione delle differenze alle voci di configurazione (init/Kconfig). Nell'esempio riportato non sembra accadere ma inciampa dopo.

Confermo che al momento sto usando un 2.6.38-rc8-git3 e, grazie al famoso TTY-based group scheduling, è abbastanza simile ad un kernel ck BFS (ma quando molto carico è sempre un po' più affannato).

Il real-time schietto di Ingo Molnár non l'ho mai provato: non mi ha interessato quando era ancora mantenuto, quindi, per il momento, ho perso il tram.
Se qualcosa si incamminerà verso il mainline ne sarò ben contento.

Una cosa interessante però l'ho notata nella configurazione relativa alla riga “Processor type and features” “Timer Frequency” in cui v'è un considerevole aumento (sino a 10000) rispetto al limite dei 1000.Io ti consiglierei di non sforare i 2/3000 (personalmente mi accontento di 1000 + CONFIG_NO_HZ per aver un bell'idle tranquillo).
Il fatto è che aumentando quel valore aumenta l'overhead dovuto ai frequentissimi timer interrupt, con relativi potenziali cambi di contesto.
Non dovrebbe essere possibile notare differenze in meglio oltre il 1000 (è molto difficile che una persona normale colga ritardi di durata inferiore al millisecondo, ammetto però di non essermi messo lì a provare).

Nei 2.6.37 e 38 non mi risulta ci siano queste novità rt, ma ci sono voci che hanno nomi/descrizioni che potrebbero trarre in inganno.

[darkbasic]

Guardo io il kernel realtime lo uso tutte le settimane per fare registrazioni audio multitraccia e ti posso assicurare che è estremamente stabile. Il problema è che l'ultima patch è ormai molto datata, inoltre per uso desktop classico non ha senso secondo me.

[darkbasic]

Non uso driver proprietari, non saprei dirti.

[Gimli[2BV!2B]]

ho spuntato le voci kernel compression LZMAQuesta non la considero la scelta ottima: non serve comprimere tanto l'immagine del kernel, l'unico vantaggio è una vmlinuz più piccola ed usualmente si hanno giga di spazio a disposizione.
In termini di tempo questo comporterà un ritardo di una frazione di secondo in attesa dell'estrazione ed il risultato finale in temine di memoria occupata sarà identico qualsiasi sia l'algoritmo scelto.
La massima compressione è manna dal cielo per le distribuzioni e per installazioni su storage estremamente ristretto.
Io uso LZO, ma considero il classico GZIP una scelta altrettanto valida.
(a dirla tutta si sta spaccando in quattro un capello, ma cerco di spiegare ciò che sta dietro alle opzioni)

Per quanto riguarderebbe la dieta dimagrante, stavo pensado di usare l'utility http://cateee.net/autokernconf/ che dovrebbe sveltirmi e snellirmi il lavoro di ricerca e compilazione dei driver essenziali per il mio hardware.Quello strumento mi sembra un po' datato. Puoi provare ad usarlo ma non sono molto ottimista sul risultato.
Personalmente non ho altri strumenti di questo tipo da suggerirti.

[Gimli[2BV!2B]]

Vero, però anche il contenuto del tar.gz di oggi mi risulta datato 8/1/2009... boh.

[Gimli[2BV!2B]]

Vedo 2200 differenze tra la mia configurazione e quella di make defconfig, immagino possano essercene anche di più tra quella di distribuzione e quella personalizzata.

Ti potrei sparare un Kompare (http://www.caffeinated.me.uk/kompare/) (evitando diff liscio (http://unixhelp.ed.ac.uk/CGI/man-cgi?diff); io uso Kde4) ma non so se sia molto facile utilizzarlo sui .config del kernel.

Le voci sono relazionate tra loro da dipendenze e condizioni su stato modulo/integrato, quindi non credo sia comodo fare modifiche avendo come base le differenze di quei file.

Quando ne ho avuto bisogno ho confrontato le sezioni che mi interessavano di due configurazioni aprendo i due make menuconfig affiancati in due console.

[darkbasic]

Ma il vecchio caro lspci? Ci vogliono 5 minuti a trovare quei quattro moduli specifici per il tuo hardware, il problema è configurare tutto il resto del marasma che diventa sempre più grosso di release in release :cry:

[Gimli[2BV!2B]]

tutte ste nuove voci che vengono aggiunte di release in release e delle quali a volte non esiste una descrizione delle caratteristiche, mandano non poco in confusione sulle scelte da fare nella compilazione di ogni nuovo kernel.Non sono molto d'accordo su questa affermazione.
Ad ogni avanzamento di versione spesso sono effettivamente presenti anche un 10÷20 o più voci nuove, ma non mi sono mai trovato di fronte qualcosa che fosse assolutamente criptico.
La maggioranza è costituita da driver per nuove periferiche, il restante è spesso proposto con la scelta più adatta per un utente finale e con una breve descrizione che è spesso sufficiente per inquadrarne lo scopo. In caso di dubbi una ricerca in Goggle dà solitamente tutti i chiarimenti necessari.

Quello con cui ti stai misurando e che stai cercando di automatizzare è il primo impatto con tutte le voci disponibili.
Come dice darkbasic non è un gran problema rintracciare i driver che ti servono, ma ti trovi di fronte ad una grande quantità di altre impostazioni da analizzare ed adattare alle tue necessità ed al tuo hardware.

Una volta creata una configurazione completa, ciò che richiede più tempo, sarà molto più semplice aggiornarla di versione in versione o utilizzarla come base per macchine con hardware diverso ma scopi simili.

Con Kolivas ha appena scritto che ci vorranno alcuni giorni perché non si aspettava il 38 così presto (http://ck-hack.blogspot.com/2011/03/2638-and-bfs-ck-releases.html), dove hai letto che ha finito?
Se si tratta di una notizia di un porting di terzi sarei anche ben contento di provarlo comunque, il goup scheduling non mi soddisfa...

[pabloski]

;34716496']il goup scheduling non mi soddisfa...

notizia preoccupante

non ti soddisfa nel senso che non mantiene le promesse?

[Gimli[2BV!2B]]

L'ho già accennato qualche post fa: il sistema rimane utilizzabile anche con cpu al 100% ma si subiscono comunque sporadici ritardi.
Inoltre se si lancia un altro processo un minimo intenso il mio single core si deve arrendere.
Con il BFS di ck il sistema rimane molto utilizzabile anche caricandolo abbondantemente (per esempio si vede bene un filmato flash anche durante una compilazione, mentre con il group scheduling va molto più a scatti).

I kernel precedenti erano senz'altro molto meno interattivi in caso di sistema carico, ma non si raggiunge l'eccellenza dello scheduler "estremista" di ck.
Ricordo che sto usando un PIV 2.2, quindi risulto abbastanza sensibile alle capacità dello scheduler, probabilmente usando un pc moderno la differenza percepibile potrebbe essere minore.

[Gimli[2BV!2B]]

Ho dato un'occhiata al seme per kernel vanilla di kernel-seeds per i386.
Osservazioni che mi ha suscitato.

PRO
Si tratta di una configurazione generica, completamente priva di driver per specifiche periferiche.
Trovo condivisibili buona parte delle scelte relative alle voci non di driver: adatte ad un sistema multicore moderno.
CONTRO
Occorre comunque spulciarla quasi completamente per poterla utilizzare.
Inadatta per macchine che non siano un classico pc desktop.
Conservativa: ha attive opzioni che permettono compatibiltà con software stagionato.
Audio completamente inattivo: né ALSA né OSS.
Niente Ext4?!
Porzioni di debug attivo.
Tutte le Library routines e le Cryptographic API attive ed integrate.
Wireless disattivata, non è una cosa immediata destreggiarsi nell'attivazione.
Non sono riuscito ancora a vedere la documentazione perché mi risulta spesso irraggiungibile.
Personalmente quando trovo un'opzione oscura la cerco in Google (http://www.google.com/linux), prediligendo i risultati KernelTrap (http://kerneltrap.org/) ed articoli come questi di The H (http://www.h-online.com/open/features/What-s-new-in-Linux-2-6-38-1205467.html).

Su Arch non faccio il guastafeste, la considero una distribuzione interessante.

Il BFQ quasi quasi lo provo: il disco l'ho sempre trascurato, magari ottengo un miglioramento.

P.S. non guardare solo la dimensione della vmlinuz: lsmod che dice? E dmesg | grep -e "Memory\|Freeing"
Per finire i moduli: du -sh /lib/modules/$(uname -r)/

[Gimli[2BV!2B]]

Per la gioia di grandi e piccini, 2.6.38-ck1! (http://ck-hack.blogspot.com/2011/03/2638-ck1-bfs-0363-for-2638.html)

Confermo che la differenze è percettibile sul mio single core, non enorme ma apprezzabile.

[Gimli[2BV!2B]]

Correggo, la differenza si nota eccome: vado alla console per lanciare la compilazione del kernel patchato con BFQ (suggerito da LinuxOs) e mi rendo conto che ha quasi finito.

Nel frattempo ho navigato, pasticciato con la collezione musicale in Amarok, visto filmatini Flash e aperto Eclipse dimenticandomi della compilazione...

[Axl_Mas]

Patch BFQ (disk scheduling) e Patch BFS (cpu scheduling) eseguite con successo :D


Il BFS lo uso da quando è uscita la prima versione, questo BFQ non lo conoscevo ma facendo una ricerchina sembra che dia davvero un grosso aumento delle prestazioni del disco!!!

Che mi dite a riguardo del bfq?Ha qualche controindicazione/problema o solo effetti benefici?

E un'ultima domanda: che differenza c'è tra la semplice patch bfs e la ck1?

[darkbasic]

Che mi dite a riguardo del bfq?Ha qualche controindicazione/problema o solo effetti benefici?

Quando si parla di scheduler le controindicazioni ci sono SEMPRE :)

[Axl_Mas]

Quando si parla di scheduler le controindicazioni ci sono SEMPRE :)

Nello specifico del bfq?

[Gimli[2BV!2B]]

Il BFQ (Budget Fair Queueing) è stato scritto con scopi simili al BFS: ridurre la latenza del sistema distribuendo le risorse in modo prioritario ai programmi interattivi, lasciando in secondo piano processi che cercano di accaparrarsi tutte le risorse disponibili. (http://algo.ing.unimo.it/people/paolo/disk_sched/description.php)

Lo scheduler di I/O standard del kernel, il CFQ (Completely Fair Queuing) ha alla sua base un concetto di questo tipo: code di processi che richiedono accesso al disco a cui viene dato pieno accesso per fette di tempo fisse, a rotazione (pesati in base ad eventuali priorità impostate (http://linux.die.net/man/1/ionice)).
Anche in caso di processi con priorità bassa questi potrebbero accaparrarsi la maggior parte delle risorse impantanando il sistema.

Il BFQ invece analizza il comportamento dei processi, determinando quali tendono a fare troppe richieste. La priorità di questi viene ridotta automaticamente, permettendo al sistema di portare a termine nel minor tempo possibile brevi richieste di accesso al disco anche quando la risorsa è pesantemente sfruttata.
Le richieste brevi sono solitamente fatte da programmi interattivi, il risultato dovrebbe essere quindi una riduzione della latenza ed una maggiore efficienza del flusso di dati da e verso le periferiche di archiviazione.
Il Group Scheduling devo ancora analizzarlo.

Questo scheduler dovrebbe essere quindi consigliabile per macchine tese ad utilizzo interattivo.
Per contro sul sito viene riportato che, pur derivando dal CFQ, non sono state reimportate alcune modifiche introdotte in questo scheduler dal momento del "fork" in poi, come failsafe queue allocation, simplified dispatch cycle (una veloce ricerca non mi ha illuminato su queste due feature), ottimizzazioni per SSD, ecc...

Come ho scritto lo sto provando per la prima volta, l'attuale impressione è che il miglioramento non sia percepibile come con il BFS, anche perché, solitamente, non stresso particolarmente il disco durante il mio utilizzo normale del pc.

[Axl_Mas]

Grazie Gimli per la risposta davvero professionale!!

[Axl_Mas]

Sono andato a scaricare la pathc bfq ma ho trovato 3 patch
http://algo.ing.unimo.it/people/paolo/disk_sched/sources.php

Devo scaricare e applicare tutte e 3 o solo una?Se si quale?

[EDIT] Ho trovato, devo installarle tutte e 3 :)

[Gimli[2BV!2B]]

Da quando ho usato Gentoo ho smesso (pigrizia...) di usare make-kpkg.
Il classico make install si ostina a crearmi una initrd.img nonostante non me ne importi nulla; ho spulciato il makefile e cercato qua e là ma non son riuscito a capire come spiegargli che non la voglio.

Suggerimenti? Ora la elimino manualmente subito dopo l'installazione, ma preferirei evitare di crearla.

[ezln]

;37051155']Da quando ho usato Gentoo ho smesso (pigrizia...) di usare make-kpkg.
Il classico make install si ostina a crearmi una initrd.img nonostante non me ne importi nulla; ho spulciato il makefile e cercato qua e là ma non son riuscito a capire come spiegargli che non la voglio.

Suggerimenti? Ora la elimino manualmente subito dopo l'installazione, ma preferirei evitare di crearla.

Ciao, Gimli. Io pensavo che fosse la regola avere un'initrd.img. Tanto che su gentoo, tempo fa, non mi veniva creata e 'sto fatto non mi piaceva...:rolleyes:

[Gimli[2BV!2B]]

Ciao ezln. L'initrd non è indispensabile, praticamente è un contenitore di moduli e firmware che potrebbero servire prima che la partizione root sia montata.
Se si integrano i moduli necessari per montare la root (driver controller SATA/IDE e filesystem) e non si hanno necessità software oppure hardware particolare se ne può fare a meno.

[ezln]

;37058057']Ciao ezln. L'initrd non è indispensabile, praticamente è un contenitore di moduli e firmware che potrebbero servire prima che la partizione root sia montata.
Se si integrano i moduli necessari per montare la root (driver controller SATA/IDE e filesystem) e non si hanno necessità software oppure hardware particolare se ne può fare a meno.

Grazie per la risposta, impeccabile come al solito.:O ;)

[Gimli[2BV!2B]]

Da una settimana 3.3.1-ck1, ed ho ricominciato ad usare make-kpkg.wget http://ck.kolivas.org/patches/3.0/3.3/3.3-ck1/3.3-ck1-broken-out.tar.bz2
rm -R patches
tar xjf 3.3-ck1-broken-out.tar.bz2
patch -p1 -d linux-3.3 < patches/3.3-sched-bfs-420.patch
patch -p1 -d linux-3.3 < patches/kconfig-expose_vmsplit_option.patch
patch -p1 -d linux-3.3 < patches/hz-default_1000.patch
patch -p1 -d linux-3.3 < patches/hz-no_default_250.patch
patch -p1 -d linux-3.3 < patches/hz-raise_max.patch
patch -p1 -d linux-3.3 < patches/preempt-desktop-tune.patch
patch -p1 -d linux-3.3 < patches/ck1-version.patch
wget http://www.kernel.org/pub/linux/kernel/v3.0/patch-3.3.1.xz
patch -p1 -d linux-3.3 < <(xzcat patch-3.3.1.xz)
mv linux-3.3 linux-3.3.1-ck1
cp linux-3.2-ck1/.config linux-3.3.1-ck1/
cd linux-3.3.1-ck1
make oldconfig
make menuconfig
fakeroot make-kpkg --append-to-version "-kwankey" --revision 1 kernel_image kernel_headersMi ero disabituato, ma in Debian e famiglia è molto meglio usare make-kpkg.
A parte la questione initrd, toglie vari passaggi e crea un pacchetto con nome di versione allineato a quelli standard. Inoltre il pacchetto invoca tutti i processi pre-install, post-install sistemando Grub, dkms, ecc...
Per non parlare della comoda pulizia col purge dei pacchetti obsoleti.

Restava giusto un problema: i symlink in /lib/modules del kernel installato finivano per puntare alla cartella in cui si era fatta la compilazione.
Questo creava fastidi se si cancellava o rinomina quella cartella prima della disinstallazione del relativo kernel.
Però, solitamente, si crea anche un bel pacchetto di headers compatto e stabile, perché non usare quelli, come nei kernel da repository?
gimli@kwankey:~$ cat /etc/kernel/header_postinst.d/symlinks
#!/bin/bash

# We're passed the version of the kernel being installed
inst_kern=$1

uname_s=$(uname -s)

_get_build_dir() {
KVER=$1
case ${uname_s} in
Linux) DIR="/lib/modules/$KVER/build" ;;
esac
echo $DIR
}

_get_source_dir() {
KVER=$1
case ${uname_s} in
Linux) DIR="/lib/modules/$KVER/source" ;;
esac
echo $DIR
}

_get_headers_dir() {
KHDRS=$1
case ${uname_s} in
Linux) DIR="/usr/src/$KHDRS" ;;
esac
echo $DIR
}

case "${uname_s}" in
Linux)
header_pkg="linux-headers-$inst_kern"
kernel="Linux"
;;
esac

DIR_BUILD=$(_get_build_dir $inst_kern )
DIR_SOURCE=$(_get_source_dir $inst_kern )
DIR_HEADERS=$(_get_headers_dir $header_pkg )

if [ -h "$DIR_BUILD" -a -d "$DIR_HEADERS" ] ; then
rm "$DIR_BUILD"
ln -s "$DIR_HEADERS" "$DIR_BUILD"
fi

if [ -h "$DIR_SOURCE" -a -d "$DIR_HEADERS" ] ; then
rm "$DIR_SOURCE"
ln -s "$DIR_HEADERS" "$DIR_SOURCE"
fiL'ho scritto ora e testato una sola volta, mi sembra sicuro e corretto, ma lo ricontrollerò.

[Gimli[2BV!2B]]

Probabilmente CK rilascerà la patch per il kernel 3.4 con un po' di ritardo.
Se qualcuno fosse interessato ad utilizzare la patch per 3.3 con le minime correzioni necessarie per farla funzionare sul 3.4, senza garanzie sul risultato posso riportare le poche modifiche necessarie.
L'ho utilizzata intensamente su un solo sistema 32bit single core per qualche giorno dove non ha evidenziato errori o comportamenti anomali.Linux kwankey 3.4.0-ck1-kwankey #3 PREEMPT Sun May 27 17:51:34 CEST 2012 i686 GNU/Linux

[Axl_Mas]

;37548493']Probabilmente CK rilascerà la patch per il kernel 3.4 con un po' di ritardo.
Se qualcuno fosse interessato ad utilizzare la patch per 3.3 con le minime correzioni necessarie per farla funzionare sul 3.4, senza garanzie sul risultato posso riportare le poche modifiche necessarie.
L'ho utilizzata intensamente su un solo sistema 32bit single core per qualche giorno dove non ha evidenziato errori o comportamenti anomali.Linux kwankey 3.4.0-ck1-kwankey #3 PREEMPT Sun May 27 17:51:34 CEST 2012 i686 GNU/Linux

Sono interessato e pronto a testare la patch su un turionII e lubuntu 64 bit...in attesa della patch ufficiale, anche se ck sembra molto impegnato ultimamente nella vita reale.

[Gimli[2BV!2B]]

Sottolineo nuovamente che non ho le competenze necessarie ed ho solamente corretto le poche incompatibilità emerse analizzando le modifiche apportate nel kernel vanilla, quindi sii conscio che potrebbe darti problemi.--- linux-3.4/kernel/sched/bfs.c 2012-05-30 22:38:17.190879529 +0200
+++ linux-3.4-ck1/kernel/sched/bfs.c 2012-05-27 17:35:27.044951773 +0200
@@ -69,6 +69,7 @@
#include <linux/slab.h>
#include <linux/init_task.h>

+#include <asm/switch_to.h>
#include <asm/tlb.h>
#include <asm/unistd.h>
#include <asm/mutex.h>
@@ -3213,7 +3214,7 @@ need_resched:
*/
if (unlikely(deactivate && blk_needs_flush_plug(prev))) {
grq_unlock_irq();
- preempt_enable_no_resched();
+ sched_preempt_enable_no_resched();
blk_schedule_flush_plug(prev);
goto need_resched;
}
@@ -3299,12 +3300,24 @@ need_resched:
grq_unlock_irq();

rerun_prev_unlocked:
- preempt_enable_no_resched();
+ sched_preempt_enable_no_resched();
if (unlikely(need_resched()))
goto need_resched;
}
EXPORT_SYMBOL(schedule);

+/**
+ * schedule_preempt_disabled - called with preemption disabled
+ *
+ * Returns with preemption disabled. Note: preempt_count must be 1
+ */
+void __sched schedule_preempt_disabled(void)
+{
+ sched_preempt_enable_no_resched();
+ schedule();
+ preempt_disable();
+}
+
#ifdef CONFIG_MUTEX_SPIN_ON_OWNER

static inline bool owner_running(struct mutex *lock, struct task_struct *owner)
@@ -3463,9 +3476,9 @@ EXPORT_SYMBOL(__wake_up);
/*
* Same as __wake_up but called with the spinlock in wait_queue_head_t held.
*/
-void __wake_up_locked(wait_queue_head_t *q, unsigned int mode)
+void __wake_up_locked(wait_queue_head_t *q, unsigned int mode, int nr)
{
- __wake_up_common(q, mode, 1, 0, NULL);
+ __wake_up_common(q, mode, nr, 0, NULL);
}
EXPORT_SYMBOL_GPL(__wake_up_locked);

@@ -4576,7 +4589,7 @@ SYSCALL_DEFINE0(sched_yield)
__release(grq.lock);
spin_release(&grq.lock.dep_map, 1, _THIS_IP_);
do_raw_spin_unlock(&grq.lock);
- preempt_enable_no_resched();
+ sched_preempt_enable_no_resched();

schedule();

Ho utilizzato le seguenti patch dell'insieme ck1:

3.3-sched-bfs-420.patch
hz-default_1000.patch
hz-no_default_250.patch
hz-raise_max.patch
preempt-desktop-tune.patch
ck1-version.patch
Si applicano tutte con qualche offset.
Alla fine ho applicato le modifiche riportate al solo (importante) file kernel/sched/bfs.c, sul modello delle novità bell'originale kernel/sched/core.c

[Gimli[2BV!2B]]

CK c'è! È uscita la nuova patch ufficiale. (http://ck-hack.blogspot.it/2012/06/bfs-0422-34-ck1.html)

[nicfio]

Ciao a tutti,

dopo alcuni mesi di utilizzo quotidiano di Linux (Distribuzione debian squeeze - ha sostituito Windows 7 sul mio PC ed è divenuto l'unico OS presente sulla mia macchina) vorrei cimentarmi a compilare, installare ed utilizzare un kernel vanilla; in proposito avrei bisogno di sapere:

- Quali pacchetti devo installare per far funzionare make xconfig?

- Considerando che voglio utlizzare il sistema standard di compilazione del kernel (non il debian-way, così anche se dovessi cambiare distribuzione quello che ho imparato non devo buttarlo via) ci sono dei consigli prima di cominciare a sbattere la testa al muro?

- I miei dischi utilizzano file system ext4: compilando il kernel con il supporto a tale filesystem come builtin, non è necessario provvedere alla creazione di un initrd, giusto?


Grazie!

[Gimli[2BV!2B]]

- Quali pacchetti devo installare per far funzionare make xconfig?Non l'ho mai usato.

xconfig richiede le librerie QT e relativi pacchetti di sviluppo
gconfig le GTK+ e relativi pacchetti di sviluppo
menuconfig richiede le librerie ncurses e relativa libreria di sviluppo (in famiglia Debian solo libncurses5-dev, se non sbaglio)

- Considerando che voglio utlizzare il sistema standard di compilazione del kernel (non il debian-way, così anche se dovessi cambiare distribuzione quello che ho imparato non devo buttarlo via) ci sono dei consigli prima di cominciare a sbattere la testa al muro?
È più scomodo.
Son sempre i soliti comandi per compilaremake
make modules
#su -
sudo make modules_install
sudo make install
Per disinstallare bisogna andare a caccia dei singoli file e cartelle (http://www.hwupgrade.it/forum/showpost.php?p=34083119&postcount=22).
Bisogna ricordarsi di fare un update-grub o equivalente altrimenti non si aggiornano le voci nel bootloader.

- I miei dischi utilizzano file system ext4: compilando il kernel con il supporto a tale filesystem come builtin, non è necessario provvedere alla creazione di un initrd, giusto?Quello ed il driver del controller SATA/PATA a cui è collegato il disco di sistema e CONFIG_BLK_DEV_SD

[Gimli[2BV!2B]]

Visto che è da metà agosto che non ci sono annunci da Con Kolivas sul suo blog mi son messo avanti con il 3.6.
Queste sono le due patch che interferiscono con la patch BFS:

[PATCH v2 2/7] cpusets, hotplug: Restructure functions that are invoked during hotplug (https://lkml.org/lkml/2012/5/4/268) cpuset_update_active_cpus( bool );
[PATCH tip/core/rcu 05/17] rcu: Use new RCU_POINTER_INITIALIZER for gcc-style initializations (https://lkml.org/lkml/2012/6/22/267)

Se non ricordo male un solo offset non viene risolto in automatico in init/main.c (print_scheduler_version() da mettere alla riga 809).

Offro quindi una patch non ufficiale da applicare alla patch ufficiale 3.5-sched-bfs-424.patch per renderla 3.6-sched-bfs-424_unofficial.patch
Sottolineo che sto utilizzando il kernel con queste patch solo da qualche ora, non sono in contatto con Con Colivas né ho approfondite conoscenze del codice del kernel.
Risulta così lunga principalmente per gli aggiornamenti di tutti gli offset, delle date e dei nomi dei file. Ho messo in grassetto le modifiche apportate.
--- patches/3.5-sched-bfs-424.patch 2012-10-05 23:34:51.359351736 +0200
+++ 3.6-sched-bfs-424.patch 2012-10-06 01:00:48.640369658 +0200
@@ -27,33 +27,11 @@ cpu usage may be very different if you h
-ck

---
- Documentation/scheduler/sched-BFS.txt | 347 +
- Documentation/sysctl/kernel.txt | 26
- arch/powerpc/platforms/cell/spufs/sched.c | 5
- arch/x86/Kconfig | 10
- drivers/cpufreq/cpufreq.c | 7
- drivers/cpufreq/cpufreq_conservative.c | 4
- drivers/cpufreq/cpufreq_ondemand.c | 8
- fs/proc/base.c | 2
- include/linux/init_task.h | 64
- include/linux/ioprio.h | 2
- include/linux/jiffies.h | 2
- include/linux/sched.h | 110
- init/Kconfig | 48
- init/main.c | 1
- kernel/delayacct.c | 2
- kernel/exit.c | 2
- kernel/posix-cpu-timers.c | 12
- kernel/sched/Makefile | 8
- kernel/sched/bfs.c | 7448 ++++++++++++++++++++++++++++++
- kernel/sysctl.c | 31
- lib/Kconfig.debug | 2
- 21 files changed, 8063 insertions(+), 78 deletions(-)

-Index: linux-3.5-ck1/arch/powerpc/platforms/cell/spufs/sched.c
+Index: linux-3.6-ck1/arch/powerpc/platforms/cell/spufs/sched.c
===================================================================
---- linux-3.5-ck1.orig/arch/powerpc/platforms/cell/spufs/sched.c 2012-01-05 10:55:44.000000000 +1100
-+++ linux-3.5-ck1/arch/powerpc/platforms/cell/spufs/sched.c 2012-08-16 13:20:26.856229061 +1000
+--- linux-3.6-ck1.orig/arch/powerpc/platforms/cell/spufs/sched.c 2012-10-05 23:37:26.870479786 +0200
++++ linux-3.6-ck1/arch/powerpc/platforms/cell/spufs/sched.c 2012-10-05 23:38:21.090826080 +0200
@@ -63,11 +63,6 @@ static struct timer_list spusched_timer;
static struct timer_list spuloadavg_timer;

@@ -66,10 +44,10 @@ Index: linux-3.5-ck1/arch/powerpc/platfo
* Frequency of the spu scheduler tick. By default we do one SPU scheduler
* tick for every 10 CPU scheduler ticks.
*/
-Index: linux-3.5-ck1/Documentation/scheduler/sched-BFS.txt
+Index: linux-3.6-ck1/Documentation/scheduler/sched-BFS.txt
===================================================================
---- /dev/null 1970-01-01 00:00:00.000000000 +0000
-+++ linux-3.5-ck1/Documentation/scheduler/sched-BFS.txt 2012-08-16 13:20:26.856229061 +1000
+--- /dev/null 2012-10-05 22:50:08.959930518 +0200
++++ linux-3.6-ck1/Documentation/scheduler/sched-BFS.txt 2012-10-05 23:38:21.091826068 +0200
@@ -0,0 +1,347 @@
+BFS - The Brain Fuck Scheduler by Con Kolivas.
+
@@ -418,10 +396,10 @@ Index: linux-3.5-ck1/Documentation/sched
+
+
+Con Kolivas <kernel@kolivas.org> Tue, 5 Apr 2011
-Index: linux-3.5-ck1/Documentation/sysctl/kernel.txt
+Index: linux-3.6-ck1/Documentation/sysctl/kernel.txt
===================================================================
---- linux-3.5-ck1.orig/Documentation/sysctl/kernel.txt 2012-03-20 17:39:40.000000000 +1100
-+++ linux-3.5-ck1/Documentation/sysctl/kernel.txt 2012-08-16 13:20:26.856229061 +1000
+--- linux-3.6-ck1.orig/Documentation/sysctl/kernel.txt 2012-10-05 23:37:27.312474702 +0200
++++ linux-3.6-ck1/Documentation/sysctl/kernel.txt 2012-10-05 23:38:21.091826068 +0200
@@ -33,6 +33,7 @@ show up in /proc/sys/kernel:
- domainname
- hostname
@@ -476,10 +454,10 @@ Index: linux-3.5-ck1/Documentation/sysct
rtsig-max & rtsig-nr:

The file rtsig-max can be used to tune the maximum number
-Index: linux-3.5-ck1/fs/proc/base.c
+Index: linux-3.6-ck1/fs/proc/base.c
===================================================================
---- linux-3.5-ck1.orig/fs/proc/base.c 2012-07-23 22:09:13.000000000 +1000
-+++ linux-3.5-ck1/fs/proc/base.c 2012-08-16 13:20:26.857229048 +1000
+--- linux-3.6-ck1.orig/fs/proc/base.c 2012-10-05 23:37:26.918479234 +0200
++++ linux-3.6-ck1/fs/proc/base.c 2012-10-05 23:38:21.092826056 +0200
@@ -338,7 +338,7 @@ static int proc_pid_stack(struct seq_fil
static int proc_pid_schedstat(struct task_struct *task, char *buffer)
{
@@ -489,11 +467,11 @@ Index: linux-3.5-ck1/fs/proc/base.c
(unsigned long long)task->sched_info.run_delay,
task->sched_info.pcount);
}
-Index: linux-3.5-ck1/include/linux/init_task.h
+Index: linux-3.6-ck1/include/linux/init_task.h
===================================================================
---- linux-3.5-ck1.orig/include/linux/init_task.h 2012-07-23 22:09:13.000000000 +1000
-+++ linux-3.5-ck1/include/linux/init_task.h 2012-08-16 13:20:26.857229048 +1000
-@@ -132,12 +132,70 @@ extern struct cred init_cred;
+--- linux-3.6-ck1.orig/include/linux/init_task.h 2012-10-05 23:37:26.960478752 +0200
++++ linux-3.6-ck1/include/linux/init_task.h 2012-10-06 00:16:57.016596435 +0200
+@@ -141,12 +141,70 @@ extern struct task_group root_task_group
# define INIT_PERF_EVENTS(tsk)
#endif

@@ -530,8 +508,8 @@ Index: linux-3.5-ck1/include/linux/init_
+ .children = LIST_HEAD_INIT(tsk.children), \
+ .sibling = LIST_HEAD_INIT(tsk.sibling), \
+ .group_leader = &tsk, \
-+ RCU_INIT_POINTER(.real_cred, &init_cred), \
-+ RCU_INIT_POINTER(.cred, &init_cred), \
++ RCU_POINTER_INITIALIZER(real_cred, &init_cred), \
++ RCU_POINTER_INITIALIZER(cred, &init_cred), \
+ .comm = INIT_TASK_COMM, \
+ .thread = INIT_THREAD, \
+ .fs = &init_fs, \
@@ -566,7 +544,7 @@ Index: linux-3.5-ck1/include/linux/init_
#define INIT_TASK(tsk) \
{ \
.state = 0, \
-@@ -201,7 +259,7 @@ extern struct cred init_cred;
+@@ -211,7 +269,7 @@ extern struct task_group root_task_group
INIT_TASK_RCU_PREEMPT(tsk) \
INIT_CPUSET_SEQ \
}
@@ -575,10 +553,10 @@ Index: linux-3.5-ck1/include/linux/init_

#define INIT_CPU_TIMERS(cpu_timers) \
{ \
-Index: linux-3.5-ck1/include/linux/ioprio.h
+Index: linux-3.6-ck1/include/linux/ioprio.h
===================================================================
---- linux-3.5-ck1.orig/include/linux/ioprio.h 2012-07-23 22:09:13.000000000 +1000
-+++ linux-3.5-ck1/include/linux/ioprio.h 2012-08-16 13:20:26.857229048 +1000
+--- linux-3.6-ck1.orig/include/linux/ioprio.h 2012-10-05 23:37:26.974478590 +0200
++++ linux-3.6-ck1/include/linux/ioprio.h 2012-10-05 23:38:21.093826044 +0200
@@ -52,6 +52,8 @@ enum {
*/
static inline int task_nice_ioprio(struct task_struct *task)
@@ -588,10 +566,10 @@ Index: linux-3.5-ck1/include/linux/iopri
return (task_nice(task) + 20) / 5;
}

-Index: linux-3.5-ck1/include/linux/sched.h
+Index: linux-3.6-ck1/include/linux/sched.h
===================================================================
---- linux-3.5-ck1.orig/include/linux/sched.h 2012-07-23 22:09:13.000000000 +1000
-+++ linux-3.5-ck1/include/linux/sched.h 2012-08-16 13:22:15.548890213 +1000
+--- linux-3.6-ck1.orig/include/linux/sched.h 2012-10-05 23:37:26.961478740 +0200
++++ linux-3.6-ck1/include/linux/sched.h 2012-10-05 23:47:10.304372168 +0200
@@ -37,8 +37,15 @@
#define SCHED_FIFO 1
#define SCHED_RR 2
@@ -618,7 +596,7 @@ Index: linux-3.5-ck1/include/linux/sched
#if defined(CONFIG_SMP) && defined(CONFIG_NO_HZ)
extern void select_nohz_load_balancer(int stop_tick);
extern void set_cpu_sd_state_idle(void);
-@@ -1235,15 +1240,31 @@ struct task_struct {
+@@ -1240,15 +1245,32 @@ struct task_struct {

#ifdef CONFIG_SMP
struct llist_node wake_entry;
@@ -649,10 +627,11 @@ Index: linux-3.5-ck1/include/linux/sched
struct sched_entity se;
struct sched_rt_entity rt;
+#endif
-
- #ifdef CONFIG_PREEMPT_NOTIFIERS
- /* list of struct preempt_notifier: */
-@@ -1352,6 +1373,9 @@ struct task_struct {
++
+ #ifdef CONFIG_CGROUP_SCHED
+ struct task_group *sched_task_group;
+ #endif
+@@ -1360,6 +1382,9 @@ struct task_struct {
int __user *clear_child_tid; /* CLONE_CHILD_CLEARTID */

cputime_t utime, stime, utimescaled, stimescaled;
@@ -662,7 +641,7 @@ Index: linux-3.5-ck1/include/linux/sched
cputime_t gtime;
#ifndef CONFIG_VIRT_CPU_ACCOUNTING
cputime_t prev_utime, prev_stime;
-@@ -1585,6 +1609,64 @@ struct task_struct {
+@@ -1591,6 +1616,64 @@ struct task_struct {
#endif
};

@@ -727,7 +706,7 @@ Index: linux-3.5-ck1/include/linux/sched
/* Future-safe accessor for struct task_struct's cpus_allowed. */
#define tsk_cpus_allowed(tsk) (&(tsk)->cpus_allowed)

-@@ -1602,10 +1684,20 @@ struct task_struct {
+@@ -1608,10 +1691,20 @@ struct task_struct {
*/

#define MAX_USER_RT_PRIO 100
@@ -750,7 +729,7 @@ Index: linux-3.5-ck1/include/linux/sched

static inline int rt_prio(int prio)
{
-@@ -1976,7 +2068,7 @@ extern unsigned long long
+@@ -1989,7 +2082,7 @@ extern unsigned long long
task_sched_runtime(struct task_struct *task);

/* sched_exec is called by processes performing an exec */
@@ -759,7 +738,7 @@ Index: linux-3.5-ck1/include/linux/sched
extern void sched_exec(void);
#else
#define sched_exec() {}
-@@ -2692,7 +2784,7 @@ static inline unsigned int task_cpu(cons
+@@ -2705,7 +2798,7 @@ static inline unsigned int task_cpu(cons
return 0;
}

@@ -768,10 +747,10 @@ Index: linux-3.5-ck1/include/linux/sched
{
}

-Index: linux-3.5-ck1/init/Kconfig
+Index: linux-3.6-ck1/init/Kconfig
===================================================================
---- linux-3.5-ck1.orig/init/Kconfig 2012-07-23 22:09:13.000000000 +1000
-+++ linux-3.5-ck1/init/Kconfig 2012-08-16 13:20:26.857229048 +1000
+--- linux-3.6-ck1.orig/init/Kconfig 2012-10-05 23:37:27.259475313 +0200
++++ linux-3.6-ck1/init/Kconfig 2012-10-05 23:38:21.094826032 +0200
@@ -32,6 +32,19 @@ config BUILDTIME_EXTABLE_SORT

menu "General setup"
@@ -800,7 +779,7 @@ Index: linux-3.5-ck1/init/Kconfig
help
Provides a simple Resource Controller for monitoring the
total CPU consumed by the tasks in a cgroup.
-@@ -763,6 +777,7 @@ config CGROUP_PERF
+@@ -778,6 +792,7 @@ config CGROUP_PERF

menuconfig CGROUP_SCHED
bool "Group CPU scheduler"
@@ -808,7 +787,7 @@ Index: linux-3.5-ck1/init/Kconfig
default n
help
This feature lets CPU scheduler recognize task groups and control CPU
-@@ -1027,6 +1042,7 @@ config UIDGID_STRICT_TYPE_CHECKS
+@@ -1042,6 +1057,7 @@ config UIDGID_STRICT_TYPE_CHECKS

config SCHED_AUTOGROUP
bool "Automatic process group scheduling"
@@ -816,7 +795,7 @@ Index: linux-3.5-ck1/init/Kconfig
select EVENTFD
select CGROUPS
select CGROUP_SCHED
-@@ -1411,38 +1427,8 @@ config COMPAT_BRK
+@@ -1426,38 +1442,8 @@ config COMPAT_BRK

On non-ancient distros (post-2000 ones) N is usually a safe choice.

@@ -856,22 +835,23 @@ Index: linux-3.5-ck1/init/Kconfig

config MMAP_ALLOW_UNINITIALIZED
bool "Allow mmapped anonymous memory to be uninitialized"
-Index: linux-3.5-ck1/init/main.c
+Index: linux-3.6-ck1/init/main.c
===================================================================
---- linux-3.5-ck1.orig/init/main.c 2012-07-23 22:09:13.000000000 +1000
-+++ linux-3.5-ck1/init/main.c 2012-08-16 13:20:26.858229035 +1000
-@@ -804,6 +804,7 @@ static noinline int init_post(void)
+--- linux-3.6-ck1.orig/init/main.c 2012-10-05 23:37:27.259475313 +0200
++++ linux-3.6-ck1/init/main.c 2012-10-06 00:44:46.401138713 +0200
+@@ -806,6 +806,8 @@ static noinline int init_post(void)
system_state = SYSTEM_RUNNING;
numa_default_policy();

+ print_scheduler_version();
-
++
current->signal->flags |= SIGNAL_UNKILLABLE;
+ flush_delayed_fput();

-Index: linux-3.5-ck1/kernel/delayacct.c
+Index: linux-3.6-ck1/kernel/delayacct.c
===================================================================
---- linux-3.5-ck1.orig/kernel/delayacct.c 2012-01-05 10:55:44.000000000 +1100
-+++ linux-3.5-ck1/kernel/delayacct.c 2012-08-16 13:20:26.858229035 +1000
+--- linux-3.6-ck1.orig/kernel/delayacct.c 2012-10-05 23:37:27.305474783 +0200
++++ linux-3.6-ck1/kernel/delayacct.c 2012-10-05 23:38:21.094826032 +0200
@@ -130,7 +130,7 @@ int __delayacct_add_tsk(struct taskstats
*/
t1 = tsk->sched_info.pcount;
@@ -881,10 +861,10 @@ Index: linux-3.5-ck1/kernel/delayacct.c

d->cpu_count += t1;

-Index: linux-3.5-ck1/kernel/exit.c
+Index: linux-3.6-ck1/kernel/exit.c
===================================================================
---- linux-3.5-ck1.orig/kernel/exit.c 2012-07-23 22:09:13.000000000 +1000
-+++ linux-3.5-ck1/kernel/exit.c 2012-08-16 13:20:26.858229035 +1000
+--- linux-3.6-ck1.orig/kernel/exit.c 2012-10-05 23:37:27.301474829 +0200
++++ linux-3.6-ck1/kernel/exit.c 2012-10-05 23:38:21.095826020 +0200
@@ -145,7 +145,7 @@ static void __exit_signal(struct task_st
sig->inblock += task_io_get_inblock(tsk);
sig->oublock += task_io_get_oublock(tsk);
@@ -894,10 +874,10 @@ Index: linux-3.5-ck1/kernel/exit.c
}

sig->nr_threads--;
-Index: linux-3.5-ck1/kernel/posix-cpu-timers.c
+Index: linux-3.6-ck1/kernel/posix-cpu-timers.c
===================================================================
---- linux-3.5-ck1.orig/kernel/posix-cpu-timers.c 2012-03-20 17:39:43.000000000 +1100
-+++ linux-3.5-ck1/kernel/posix-cpu-timers.c 2012-08-16 13:20:26.858229035 +1000
+--- linux-3.6-ck1.orig/kernel/posix-cpu-timers.c 2012-10-05 23:37:27.300474841 +0200
++++ linux-3.6-ck1/kernel/posix-cpu-timers.c 2012-10-05 23:38:21.095826020 +0200
@@ -495,7 +495,7 @@ static void cleanup_timers(struct list_h
void posix_cpu_timers_exit(struct task_struct *tsk)
{
@@ -952,11 +932,11 @@ Index: linux-3.5-ck1/kernel/posix-cpu-ti
};

if (task_cputime_expired(&task_sample, &tsk->cputime_expires))
-Index: linux-3.5-ck1/kernel/sysctl.c
+Index: linux-3.6-ck1/kernel/sysctl.c
===================================================================
---- linux-3.5-ck1.orig/kernel/sysctl.c 2012-06-01 21:37:23.000000000 +1000
-+++ linux-3.5-ck1/kernel/sysctl.c 2012-08-16 13:20:26.858229035 +1000
-@@ -126,7 +126,12 @@ static int __maybe_unused one = 1;
+--- linux-3.6-ck1.orig/kernel/sysctl.c 2012-10-05 23:37:27.300474841 +0200
++++ linux-3.6-ck1/kernel/sysctl.c 2012-10-05 23:38:21.095826020 +0200
+@@ -127,7 +127,12 @@ static int __maybe_unused one = 1;
static int __maybe_unused two = 2;
static int __maybe_unused three = 3;
static unsigned long one_ul = 1;
@@ -970,7 +950,7 @@ Index: linux-3.5-ck1/kernel/sysctl.c
#ifdef CONFIG_PRINTK
static int ten_thousand = 10000;
#endif
-@@ -241,7 +246,7 @@ static struct ctl_table sysctl_base_tabl
+@@ -247,7 +252,7 @@ static struct ctl_table sysctl_base_tabl
{ }
};

@@ -979,7 +959,7 @@ Index: linux-3.5-ck1/kernel/sysctl.c
static int min_sched_granularity_ns = 100000; /* 100 usecs */
static int max_sched_granularity_ns = NSEC_PER_SEC; /* 1 second */
static int min_wakeup_granularity_ns; /* 0 usecs */
-@@ -256,6 +261,7 @@ static int max_extfrag_threshold = 1000;
+@@ -262,6 +267,7 @@ static int max_extfrag_threshold = 1000;
#endif

static struct ctl_table kern_table[] = {
@@ -987,7 +967,7 @@ Index: linux-3.5-ck1/kernel/sysctl.c
{
.procname = "sched_child_runs_first",
.data = &sysctl_sched_child_runs_first,
-@@ -373,6 +379,7 @@ static struct ctl_table kern_table[] = {
+@@ -379,6 +385,7 @@ static struct ctl_table kern_table[] = {
.extra1 = &one,
},
#endif
@@ -995,7 +975,7 @@ Index: linux-3.5-ck1/kernel/sysctl.c
#ifdef CONFIG_PROVE_LOCKING
{
.procname = "prove_locking",
-@@ -840,6 +847,26 @@ static struct ctl_table kern_table[] = {
+@@ -846,6 +853,26 @@ static struct ctl_table kern_table[] = {
.proc_handler = proc_dointvec,
},
#endif
@@ -1022,10 +1002,10 @@ Index: linux-3.5-ck1/kernel/sysctl.c
#if defined(CONFIG_S390) && defined(CONFIG_SMP)
{
.procname = "spin_retry",
-Index: linux-3.5-ck1/lib/Kconfig.debug
+Index: linux-3.6-ck1/lib/Kconfig.debug
===================================================================
---- linux-3.5-ck1.orig/lib/Kconfig.debug 2012-07-23 22:09:13.000000000 +1000
-+++ linux-3.5-ck1/lib/Kconfig.debug 2012-08-16 13:20:26.859229023 +1000
+--- linux-3.6-ck1.orig/lib/Kconfig.debug 2012-10-05 23:37:26.939478992 +0200
++++ linux-3.6-ck1/lib/Kconfig.debug 2012-10-05 23:38:21.095826020 +0200
@@ -913,7 +913,7 @@ config BOOT_PRINTK_DELAY

config RCU_TORTURE_TEST
@@ -1035,11 +1015,11 @@ Index: linux-3.5-ck1/lib/Kconfig.debug
default n
help
This option provides a kernel module that runs torture tests
-Index: linux-3.5-ck1/include/linux/jiffies.h
+Index: linux-3.6-ck1/include/linux/jiffies.h
===================================================================
---- linux-3.5-ck1.orig/include/linux/jiffies.h 2012-01-05 10:55:44.000000000 +1100
-+++ linux-3.5-ck1/include/linux/jiffies.h 2012-08-16 13:20:26.859229023 +1000
-@@ -164,7 +164,7 @@ static inline u64 get_jiffies_64(void)
+--- linux-3.6-ck1.orig/include/linux/jiffies.h 2012-10-05 23:37:26.971478624 +0200
++++ linux-3.6-ck1/include/linux/jiffies.h 2012-10-05 23:38:21.096826008 +0200
+@@ -173,7 +173,7 @@ static inline u64 get_jiffies_64(void)
* Have the 32 bit jiffies value wrap 5 minutes after boot
* so jiffies wrap bugs show up earlier.
*/
@@ -1048,10 +1028,10 @@ Index: linux-3.5-ck1/include/linux/jiffi

/*
* Change timeval to jiffies, trying to avoid the
-Index: linux-3.5-ck1/drivers/cpufreq/cpufreq.c
+Index: linux-3.6-ck1/drivers/cpufreq/cpufreq.c
===================================================================
---- linux-3.5-ck1.orig/drivers/cpufreq/cpufreq.c 2012-06-01 21:37:21.000000000 +1000
-+++ linux-3.5-ck1/drivers/cpufreq/cpufreq.c 2012-08-16 13:20:26.859229023 +1000
+--- linux-3.6-ck1.orig/drivers/cpufreq/cpufreq.c 2012-10-05 23:37:27.003478256 +0200
++++ linux-3.6-ck1/drivers/cpufreq/cpufreq.c 2012-10-05 23:38:21.096826008 +0200
@@ -28,6 +28,7 @@
#include <linux/cpu.h>
#include <linux/completion.h>
@@ -1060,7 +1040,7 @@ Index: linux-3.5-ck1/drivers/cpufreq/cpu
#include <linux/syscore_ops.h>

#include <trace/events/power.h>
-@@ -1457,6 +1458,12 @@ int __cpufreq_driver_target(struct cpufr
+@@ -1476,6 +1477,12 @@ int __cpufreq_driver_target(struct cpufr
target_freq, relation);
if (cpu_online(policy->cpu) && cpufreq_driver->target)
retval = cpufreq_driver->target(policy, target_freq, relation);
@@ -1073,10 +1053,10 @@ Index: linux-3.5-ck1/drivers/cpufreq/cpu

return retval;
}
-Index: linux-3.5-ck1/drivers/cpufreq/cpufreq_ondemand.c
+Index: linux-3.6-ck1/drivers/cpufreq/cpufreq_ondemand.c
===================================================================
---- linux-3.5-ck1.orig/drivers/cpufreq/cpufreq_ondemand.c 2012-06-01 21:37:21.000000000 +1000
-+++ linux-3.5-ck1/drivers/cpufreq/cpufreq_ondemand.c 2012-08-16 13:20:26.859229023 +1000
+--- linux-3.6-ck1.orig/drivers/cpufreq/cpufreq_ondemand.c 2012-10-05 23:37:27.002478268 +0200
++++ linux-3.6-ck1/drivers/cpufreq/cpufreq_ondemand.c 2012-10-05 23:38:21.096826008 +0200
@@ -28,8 +28,8 @@
* It helps to keep variable names smaller, simpler
*/
@@ -1101,10 +1081,10 @@ Index: linux-3.5-ck1/drivers/cpufreq/cpu
*
* Any frequency increase takes it to the maximum frequency.
* Frequency reduction happens at minimum steps of
-Index: linux-3.5-ck1/drivers/cpufreq/cpufreq_conservative.c
+Index: linux-3.6-ck1/drivers/cpufreq/cpufreq_conservative.c
===================================================================
---- linux-3.5-ck1.orig/drivers/cpufreq/cpufreq_conservative.c 2012-03-20 17:39:41.000000000 +1100
-+++ linux-3.5-ck1/drivers/cpufreq/cpufreq_conservative.c 2012-08-16 13:20:26.859229023 +1000
+--- linux-3.6-ck1.orig/drivers/cpufreq/cpufreq_conservative.c 2012-10-05 23:37:27.003478256 +0200
++++ linux-3.6-ck1/drivers/cpufreq/cpufreq_conservative.c 2012-10-05 23:38:21.096826008 +0200
@@ -29,8 +29,8 @@
* It helps to keep variable names smaller, simpler
*/
@@ -1116,11 +1096,11 @@ Index: linux-3.5-ck1/drivers/cpufreq/cpu

/*
* The polling frequency of this governor depends on the capability of
-Index: linux-3.5-ck1/arch/x86/Kconfig
+Index: linux-3.6-ck1/arch/x86/Kconfig
===================================================================
---- linux-3.5-ck1.orig/arch/x86/Kconfig 2012-07-23 22:09:12.000000000 +1000
-+++ linux-3.5-ck1/arch/x86/Kconfig 2012-08-16 13:20:26.860229011 +1000
-@@ -795,15 +795,7 @@ config SCHED_MC
+--- linux-3.6-ck1.orig/arch/x86/Kconfig 2012-10-05 23:37:26.856479947 +0200
++++ linux-3.6-ck1/arch/x86/Kconfig 2012-10-05 23:38:21.097825996 +0200
+@@ -797,15 +797,7 @@ config SCHED_MC
increased overhead in some places. If unsure say N here.

config IRQ_TIME_ACCOUNTING
@@ -1137,10 +1117,10 @@ Index: linux-3.5-ck1/arch/x86/Kconfig

source "kernel/Kconfig.preempt"

-Index: linux-3.5-ck1/kernel/sched/bfs.c
+Index: linux-3.6-ck1/kernel/sched/bfs.c
===================================================================
---- /dev/null 1970-01-01 00:00:00.000000000 +0000
-+++ linux-3.5-ck1/kernel/sched/bfs.c 2012-08-16 13:27:10.367258721 +1000
+--- /dev/null 2012-10-05 22:50:08.959930518 +0200
++++ linux-3.6-ck1/kernel/sched/bfs.c 2012-10-06 00:22:53.154238527 +0200
@@ -0,0 +1,7448 @@
+/*
+ * kernel/sched/bfs.c, was kernel/sched.c
@@ -8097,7 +8077,7 @@ Index: linux-3.5-ck1/kernel/sched/bfs.c
+ switch (action & ~CPU_TASKS_FROZEN) {
+ case CPU_ONLINE:
+ case CPU_DOWN_FAILED:
-+ cpuset_update_active_cpus();
++ cpuset_update_active_cpus(true);
+ return NOTIFY_OK;
+ default:
+ return NOTIFY_DONE;
@@ -8109,7 +8089,7 @@ Index: linux-3.5-ck1/kernel/sched/bfs.c
+{
+ switch (action & ~CPU_TASKS_FROZEN) {
+ case CPU_DOWN_PREPARE:
-+ cpuset_update_active_cpus();
++ cpuset_update_active_cpus(false);
+ return NOTIFY_OK;
+ default:
+ return NOTIFY_DONE;
@@ -8590,10 +8570,10 @@ Index: linux-3.5-ck1/kernel/sched/bfs.c
+ return smt_gain;
+}
+#endif
-Index: linux-3.5-ck1/kernel/sched/Makefile
+Index: linux-3.6-ck1/kernel/sched/Makefile
===================================================================
---- linux-3.5-ck1.orig/kernel/sched/Makefile 2012-07-23 22:09:13.000000000 +1000
-+++ linux-3.5-ck1/kernel/sched/Makefile 2012-08-16 13:20:26.862228987 +1000
+--- linux-3.6-ck1.orig/kernel/sched/Makefile 2012-10-05 23:37:27.304474794 +0200
++++ linux-3.6-ck1/kernel/sched/Makefile 2012-10-05 23:38:21.099825972 +0200
@@ -11,8 +11,12 @@ ifneq ($(CONFIG_SCHED_OMIT_FRAME_POINTER
CFLAGS_core.o := $(PROFILING) -fno-omit-frame-pointer
endif

gimli@sertan ~/Desktop $ uname -a
Linux sertan 3.6.0-gentoo-ck1 #1 SMP PREEMPT Fri Oct 5 20:47:53 CEST 2012 x86_64 Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz GenuineIntel GNU/Linux

[Axl_Mas]

Ottimo lavoro, grazie!
Purtroppo Con deve aver avuto problemi gravi, sul blog scrive che ha subito una tragedia in famiglia ed è in ritardo con la patch per il 3.6 :(
Appena ho un attimo testo la tua patch!!! ;)

[Gimli[2BV!2B]]

Oh, cavolo, l'ho letto adesso nei commenti dell'ultimo post :(

[Gimli[2BV!2B]]

Da un paio di settimane Con Kolivas ha aggiornato la sua patch al kernel 3.7.x.
Riporto anche il comando di compilazione che utilizzo in Gentoo in questo periodo.mount /boot ; KCFLAGS="-march=native -O2 -pipe" KCPPFLAGS="-march=native -O2 -pipe" make -j9 && make modules_install && make install && grub2-mkconfig -o /boot/grub2/grub.cfg

[Axl_Mas]

;38764083']Da un paio di settimane Con Kolivas ha aggiornato la sua patch al kernel 3.7.x.
Riporto anche il comando di compilazione che utilizzo in Gentoo in questo periodo.mount /boot ; KCFLAGS="-march=native -O2 -pipe" KCPPFLAGS="-march=native -O2 -pipe" make -j9 && make modules_install && make install && grub2-mkconfig -o /boot/grub2/grub.cfg

Finalmente è uscito il kernel 3.8 aspetto che esca la patch BFS e lo provo ;)

Gimli volevo farti una domanda OT ma non troppo: ho visto che con le nuone gcc si può usare una nuova ottimizzazione -Ofast che da quando ho letto dovrebbe essere -O3 che attiva qualche altra ottimizzazione.
Ma a differenza di -O3 che fino a poco tempo fa veniva sconsigliata (francamente l'ho sempre usata per compilare mplayer e mi dava diversi frame di vantaggio nel bench video rispetto a -O2 mantenendo una perfetta stablità), la -Ofast viene consigliata, e come difetto danno solo un aumento del tempo di compilazione.

Appena ho tempo farò qualche test su guadagno prestazionale e memoria usata, tu che ne pensi?

[Gimli[2BV!2B]]

Le ottimizzazioni più spinte della 2 sono rischiose con il kernel perché non garantiscono che il codice si comporti esattamente come è stato pensato/scritto.

Questo non è solitamente un problema serissimo in programmi normali.
Ricordo che alcune librerie multimediali possono guadagnare qualcosa ed alcune mi pare siano testate proprio con -O3; anche Chromium/Chrome mi risulta sia compilato di default con -O3.

Il kernel contiene codice particolare, varie porzioni di assembler, ecc...
Per esempio credo sia possibile che alcune ottimizzazioni possano decidere di modificare sequenze di chiamate che potrebbero sembrare equivalenti in programmi user-space, ottenendo invece risultati diversi quando si dialoga direttamente con l'hardware o si devono mantenere strette sincronizzazioni.
Se dovessero nascere degli errori li riscontreresti solo tu e chi avrà compilato con un config simile, lo stesso livello di ottimizzazioni ed hardware simile (lasciandoti praticamente solo col tuo problema), rendendo l'uso del sistema più frustrante solo per guadagnare un 5% di performance o giù di lì.

Personalmente mi sono accontentato di provare solo -march=native, che non sembra aver generato problemi.

[Axl_Mas]

Per caso sai come inserire i flag di ottimizzazione compilando su ubuntu con il metodo standard che per me è molto più facile e veloce (make config e make-kpkg) ?
ps: è finalmente uscita la patch bfs e ck1 rispettiva per il kernel 3.8

[Gimli[2BV!2B]]

Ho appena compilato un 3.8.2-ck1 in macchina virtuale Debian Sid usando il nuovo comando per kernel >= 3.0 (http://guide.debianizzati.org/index.php/Debian_Kernel_Howto#Compilazione_del_kernel):fakeroot make -j5 KCFLAGS="-march=native -mtune=native -O2" KCPPFLAGS="-march=native -mtune=native -O2" KDEB_PKGVERSION=1.0 deb-pkgAh, si può aggiungere V=1 in coda per vedere che i parametri imposti sono veramente utilizzati da gcc.

Pacchetti prodotti:linux-firmware-image_1.0_amd64.deb
linux-headers-3.8.2-ck1_1.0_amd64.deb
linux-image-3.8.2-ck1_1.0_amd64.deb
linux-libc-dev_1.0_amd64.debTrattandosi di una macchina virtuale ho fatto anche una prova con O3, ma la compilazione è fallita sul driver intel e1000 a cui mancava un pezzo (immagino sia stato ottimizzato via).

[Axl_Mas]

Grande!!!!! Con quel comando sono riuscito a completare la compilazione con -Ofast!!! Lascio il computer acceso in test questa notte, sperando di non fare fuori la partizione con qualche driver disco sballato dalle ottimizzazioni...a presto i benchmark e le considerazioni!! :)))

Edit: Come non detto, il kernel non parte perchè si blocca al montaggio del ramdisk (grazie al cavolo, ho estirpato tutto dal mio kernel), non esiste un modo di compilare senza? Ho provato con --help ma non c'è nessuna opzione per eliminare il initrd

[nicfio]

G....non esiste un modo di compilare senza? Ho provato con --help ma non c'è nessuna opzione per eliminare il initrd


Certo! quando configuri il kernel per la compilazione i drivers relativi al filesystem su cui risiede la root e il controller del disco di sistema devono essere indicati con "Built-In" e non come moduli.

[Axl_Mas]

Certo! quando configuri il kernel per la compilazione i drivers relativi al filesystem su cui risiede la root e il controller del disco di sistema devono essere indicati con "Built-In" e non come moduli.

Questo lo so, fino ad ora ho sempre compilato senza initrd...il fatto è che con il nuovo comando proposto da gimli mi viene compilato initrd anche se non specificato dalla linea di comando (non ho messo l'opzione --initrd).
Comunque in attesa di trovare il comando adatto ho rispuntato il supporto al ramdisk e ricompilato tutto....ora vi scrivo dalla mia lubuntu con kernel compilato per il mio k8 e con l'opzione -Ofast, per ora sembra stabile ma ad occhio non noto differenze di velocità o nei tempi di risposta, appena ho tempo faccio qualche benchmark ;)

[Gimli[2BV!2B]]

Non ho trovato un'opzione per specificare che non si desidera l'initrd alla creazione dei pacchetti, ma è possibile specificarlo all'installazione:INITRD=No dpkg -i linux-image-3.8.2-ck1_1.0_amd64.debNon ho potuto fare la prova corretta, ma nel sistema Sid (con LVM, quindi initrd necessario) il parametro INITRD=No ha impedito la creazione dell'initrd.
Ho poi provato ad installare lo stesso kernel in una Squeeze, ho rimosso l'initrd da /boot ed ho rigenerato il grub.cfg con update-grub2: il sistema si avvia normalmente.

Altra cosa che non conoscevo: se non si disattivano accuratamente tutte le opzioni relative al debug è probabile che si ottengano moduli molto grandi rimpinzati di informazioni di debug.
Si può far fare una cura dimagrante a base della variabile INSTALL_MOD_STRIP (http://www.mjmwired.net/kernel/Documentation/kbuild/kbuild.txt#148):fakeroot make -j5 KCFLAGS="-march=native -mtune=native -O2" KCPPFLAGS="-march=native -mtune=native -O2" KDEB_PKGVERSION=1.0 INSTALL_MOD_STRIP=1 deb-pkg

[nicfio]

;39140805']Altra cosa che non conoscevo: se non si disattivano accuratamente tutte le opzioni relative al debug è probabile che si ottengano moduli molto grandi rimpinzati di informazioni di debug.
Si può far fare una cura dimagrante a base della variabile INSTALL_MOD_STRIP (http://www.mjmwired.net/kernel/Documentation/kbuild/kbuild.txt#148):fakeroot make -j5 KCFLAGS="-march=native -mtune=native -O2" KCPPFLAGS="-march=native -mtune=native -O2" KDEB_PKGVERSION=1.0 INSTALL_MOD_STRIP=1 deb-pkg



Ottimo suggerimento! Nel caso in cui invece si utilizzasse il metodo standard di compilazione del kernel (non il debian-way), come fare per eliminare i simboli di debug?

[Gimli[2BV!2B]]

@nicfio, mi risulta si debba utilizzare alla fase modules_install:make INSTALL_MOD_STRIP=1 modules_installLa dimensione può diminuire del 90% (http://unix.stackexchange.com/questions/30345/why-is-my-initial-ramdisk-so-big).
Ricordo che *andre* aveva riportato di osservare un gran consumo di spazio da parte degli oggetti di compilazione (http://www.hwupgrade.it/forum/showpost.php?p=34262153&postcount=56) (ed immagino che anche il kernel risultasse ciccio); suppongo fosse questo il motivo.
Per evitare che i prodotti intermedi di compilazione occupino tanto spazio è necessario disattivare le opzioni nel .config

Queste sono le sole opzioni relative al debug che non credo sia possibile disattivare (architettura amd64):sertan ~ # grep DEBUG /usr/src/linux/.config | grep -v \#
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_DEBUG_KERNEL=y
CONFIG_HAVE_DEBUG_KMEMLEAK=yTutte le altre occupano solo spazio (ovviamente sono fondamentali se si desidera debuggare un problema, ma in condizioni normali non servono).

[Axl_Mas]

Gimli sei un grande!!!
Ora ho il kernel ottimizzato al massimo, ho aggiunto anche la stringa da te suggerita anche se comunque già ho disabilitato tutte le opzioni di debug!

[Gimli[2BV!2B]]

Il tempo schifoso m'ha spinto a revisionare il kernel (3.11.6-gentoo-ck1).
Risultati interessanti:sertan ~ # genlop -t app-office/libreoffice
* app-office/libreoffice

Sat Oct 5 13:10:41 2013 >>> app-office/libreoffice-4.1.2.3
merge time: 1 hour, 1 minute and 16 seconds.

Sun Oct 20 20:05:58 2013 >>> app-office/libreoffice-4.1.2.3
merge time: 49 minutes and 57 seconds.

sertan ~ # genlop -t media-libs/mesa
* media-libs/mesa

Sun Oct 20 16:39:47 2013 >>> media-libs/mesa-9.2.1
merge time: 2 minutes and 44 seconds.

Sun Oct 20 16:54:07 2013 >>> media-libs/mesa-9.2.1
merge time: 2 minutes and 21 seconds.
Qualcosa è cambiato negli MTRR, ricontrollati e tornati in ordine modificado CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT (http://cateee.net/lkddb/web-lkddb/MTRR_SANITIZER_SPARE_REG_NR_DEFAULT.html)=1 in 0
Frequency scaling Intel i7: da CONFIG_X86_ACPI_CPUFREQ (http://cateee.net/lkddb/web-lkddb/X86_ACPI_CPUFREQ.html) a CONFIG_X86_INTEL_PSTATE (http://cateee.net/lkddb/web-lkddb/X86_INTEL_PSTATE.html)
Forzato scaling governor performance in drivers/cpufreq/intel_pstate.c
Forzato profilo performance MSR_IA32_ENERGY_PERF_BIAS (http://manpages.ubuntu.com/manpages/precise/man8/x86_energy_perf_policy.8.html) al boot in arch/x86/kernel/cpu/intel.c
Le frequenze del processore sono ancora completamente variabili nei suoi limiti standard (i7 3770: 3.4 ÷ 3.9 GHz con TurboBoost).
Ho anche scoperto l'esistenza dello strumento turbostat (http://manpages.ubuntu.com/manpages/precise/man8/turbostat.8.html), che tra l'altro diventa meno utile adottando i driver Intel CONFIG_X86_INTEL_PSTATE perché questi aggiornano correttamente i file in /sys:sertan linux # cat /sys/devices/system/cpu/cpu*/cpufreq/cpuinfo_cur_freq
3570000
3774000
3774000
3740000
3808000
3502000
3366000
1768000Queste impostazioni sono buone per un desktop Sandy/Ivy Bridge, ma potrebbero dare buoni risultati anche in portatili non impattando eccessivamente sui consumi (l'aumento più aggressivo della capacità di elaborazione disponibile dovrebbe permettere di terminare prima le elaborazioni, ottenendo un bilancio energetico simile).

[Xemertix]

Ciao, ho compilato un kernel 3.12.10 su arch64 con queste modifiche:

Patch bfs 0.44
scheduler bfq v0.7
Trasparent Hugepage
UKSM
attivato march=native
impostato timer=1000hz (sia ticketless che non)
attivato

Impostato rr_interval=1 e poi ho modificato 99-sysctl.conf in questo modo

vm.dirty_background_bytes=33554432
vm.dirty_background_ratio=0
vm.dirty_bytes=100663296
vm.dirty_expire_centisecs=3000
vm.dirty_ratio=0
vm.dirty_writeback_centisecs=500


per ridurre l'orribile problema di stallo i/o di cui soffrono i linux64bit (ma penso anche i 32) quando si copiano ad es.10gb di dati da/a una penna usb.

Con sched_iso, schedtool ecc.. posso aumentare la priorita' di X (a proprosito, tengo attiva l'accelerazione sna in xorg.conf).

Potete consigliarmi qualche altra modifica per aumentare la reattivita' del mio sistema, sia nei casi in cui la cpu e' impegnata, sia quando c'e molta attivita i/o (con tipo un 20-30% di swap occupata)?

Vorrei raggiungere la reattivita' di windows xp...ricordo che su un vecchio pentium4 3Ghz 2gb ram e 6600gt facevo una codifica x264 mentre giocavo a battflefield 42.
E soprattutto mai avuto l'orribile problema i/o con le chiavette che pare affliggere tutti i linux http://lwn.net/Articles/572911/

Le mie specifiche attuali sono: su9300, 4gb ram, hd 4500,ssd vertex3 e uso btrfs con compressione LZO attivata.

Grazie.

[Gimli[2BV!2B]]

Ti direi... più RAM. 4 GiB non sono tanti se la tua attività principale non è navigazione in internet e intattenimento multimediale. Immagino UKMS dia una mano ma non credo possa fare miracoli, soprattutto in uso desktop.

Le impostazioni vm.dirty_xxx che riporti forzano scritture più frequenti possibili su disco, limitando le dimensioni dei buffer in RAM.
Riducono effettivamente il ritardo di umount di una chiavetta dopo scritture grandi?
Non so se l'intero sistema tragga benefici: molte scritture brevi che interrompono altri processi saranno effettivamente meglio di minori scritture più corpose? Hai trovato/fatto benchmark?

Io ho raggiunto la reattività ideale usando solo il BFS di Con Kolivas.
Sui vecchi pc AMD XP2000+/Pentium 4 Northwood 2.2 GHz con 1GiB di RAM mi permetteva di avere praticamente sempre compilazioni in esecuzione mentre facevo altro.

Ho montato stamattina il mio primo SSD (Samsung 840 EVO 120).
Questo il mio fstab:/dev/sda1 /boot ext2 noauto,noatime 1 2
/dev/sda2 / btrfs noatime,ssd,compress=lzo 0 1
/dev/sdb5 /home ext4 noatime 0 2
/dev/sdb6 /usr/portage reiserfs noatime,nolog,notail,data=writeback 0 2
/dev/sdb7 /usr/src ext4 noatime,data=writeback,barrier=0,commit=300 0 2
/dev/sdb8 /var ext4 noatime 0 2
/dev/sdb9 none swap sw 0 0
/dev/sdc1 /mnt/archive ext4 noatime 0 2Come puoi vedere uso noatime ovunque (http://www.novell.com/documentation/oes2/stor_nss_lx/data/b55ln8c.html), l'lzo come hai tu e altre cose più esoteriche in partizioni di scarsa importanza.

[Xemertix]

Non ho fatto benchmark, ma gli stalli dell'interfaccia durante il trasferimento dati su periferiche esterne sono diminuiti ma non scomparsi.

La soluzione l'ho trovata qui https://bbs.archlinux.org/viewtopic.php?id=174384

Se non erro windows scrive i dati continuamente sulla chiavetta usb, senza write cache; stavo pensando di provare a disattivarla del tutto.

Si', anche io utilizzo impostazioni simili per btrfs ovvero

# /dev/mapper/lvmpool-root
UUID=9b68e43f-c5d5-4fc5-b7d7-50b4b413a698 / btrfs rw,noatime,ssd,compress=lzo,discard 0 0

Se hai un ssd dovresti usare discard per il trim.

Il mio utilizzo principale e' invece proprio la navigazione e multimedialita', ma posso arrivare ad avere decine e decine di schede aperte.

Sto valutando l'utilizzo della zswap ed eventualmente di un kernel RT, appena sistemano il bug del mancato boot sulle ultime versioni del kernel.

[Gimli[2BV!2B]]

Il discard l'ho tralasciato perché mi sono abbastanza convinto che non serva in modelli più recenti usati lasciando una buona percentuale di spazio libero. (http://www.spinics.net/lists/raid/msg40916.html)
Resta che sto usando il disco da una manciata di ore: vedrò se troverò prove che mi convincano del contrario.

zswap potrebbe starci bene.

Un kernel RT non so se potrà darti qualcosa in più, ovviamente ci sta di provare.

[Axl_Mas]

Dopo anni di BFS a questa relase visto che in diversi hanno avuto problemini volevo riprovare CFS.
Scarico i sorgenti del kernel 3.14.4, applico solamente la patch BFQ, apro con make xconfig e cerco dove attivare il CFS.....ma non lo trovo!

E' attivato in automatico oppure? :confused:

[Gimli[2BV!2B]]

È il default, comunque abilita l'opzioneGeneral setup
--> Automatic process group scheduling
e controlla le impostazioniEnable the block layer
--> IO Schedulers

General setup
--> Control Group supportSe non sbaglio dovrebbe esser tutto in quelle voci.

P.S. io non ho avuto problemi con il mio kernel patchato -gentoo-ck1

[Axl_Mas]

Rispolvero questo vecchio ma interessantissimo thread :)

Secondo voi ha senso aggiungere il flag "-ipo" durante la compilazione dei nostri kernel ottimizzati?
Appena ho un po' ti tempo provo e vedo di eseguire qualche benchmark.

ps: ultimamente sono passato al PDS CPU scheduler + BFQ (nel frattempo incluso officialmente nel kernel) come i/o scheduler aggiornato all'ultima patch.

[Gimli[2BV!2B]]

Non ho avuto modo di fare prove con ottimizzazioni di questo tipo per il kernel.

I vantaggi maggiori sono di riduzione di dimensione in termini di rimozione di codice duplicato. (https://lwn.net/Articles/744507/) Il tutto a discapito della quantità di RAM necessaria per compilare ed ottimizzare l'intero programma in un solo, oneroso, passaggio finale.

Questa patch di Andi Kleen citata nell'articolo dovrebbe permettere di attivare queste ottimizzazioni (https://github.com/andikleen/linux-misc/commit/4c3b1f80a2a763625933dc40911d71e264e28d63) (è necessario modificare i passaggi di compilazione, non solo aggiungere le flag).

Stando al primo link sembra sia ancora utilizzabile a gennaio 2018, e probabilmente si potrebbe riuscire ad ottenere qualcosa senza fare eccessivi salti mortali... si avranno effettivi vantaggi in un pc normale? Non so, temo possano essere molte più le instabilità introdotte o il tempo perso nel provare.