Ricompilazione kernel: varie.

[joe]

Siccome sto usando il kernel 2.6.33.4-smp di default della 13.1, mi chiedevo quanto fosse utile/conveniente provare ad utilizzare un kernel un attimo più personalizzato e quali siano gli aspetti che "prioritariamente" andrebbero ritoccati (intendo per un uso casalingo del computer, niente cose particolari).

Mi ero imbattuto parecchio tempo fa in questa nuova funzionalità introdotta dalla versione 2.6.32, che da quantoavevo capito poteva portare a qualcosa di essenziale rispetto alla dotazione hardware della macchina.
viewtopic.php?f=2&t=30718

Non ho capito bene ancora come funziona ma immagino che generi un file ".config" da usare poi per lanciare il make.
Quindi penso siapossibile lanciare quel localconfig e poi il solito menuconfig per ritoccare eventualmente a mano il "config" con cui compilare... sbaglio?
Cosa ne pensate ora come ora in base alla vostra esperienza di quella funzionalità del kernel che immagino sia acora presente anche nella versione 2.6.33? Cioè funziona bene? oppure ci si trova poi con dei kernel non in grado di utilizzare alcune periferiche o giù di lì?


Mi premeva fare una domanda su un argomento che avevo già proposto poco tempo fa.
Ultimamente ho compilato diversi programmi pacchettizandoli da sorgenti. In relazione a questa operazione, la ricompilazione del kernel ha effetti benefici specie a livello di specifica della CPU?
Mi spiego:
Attualmente il kernel in uso gestisce la mia cpu trattandola immagino come una cpu generica i686.
Nel mio caso ho un "Mobile Pentium4-3.2GHz".
Ricordo che vi è il modo per specificare questo particolare in fase di configurazione del kernel. Vi riporto un pezzo del config attuale.

Codice: Seleziona tutto

CONFIG_M686=y
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set

Ecco. Ora dicevo, secondo voi, se io specificassi la voce CONFIG_PENTIUM4, otterrei dei miglioramenti visibili ad occhio a livello di funzionamento generale della macchina? E a livello di compilazione dei pacchetti otterrei dei benefici? Non so, magari dei software più performanti o roba simile?
Chiedeo perchè avevo letto se non ricordo male di un utente che aveva ricompilato kde (se non sbaglio) e notava incrementi prestazionali notevoli... bene, nella discussione era venuto fuori che il kernel in uso durante la compilazione era stato ricompilato specificando la propria CPU... e aquanto avevo capito quel particolare sarebbe stato importante per spiegare questo incremento prestazionale del software compilato.
Spero di aver spiegato comprensibilmente le domande...
Grazie per le eventuali risposte.

[hashbang]

Siccome sto usando il kernel 2.6.33.4-smp di default della 13.1, mi chiedevo quanto fosse utile/conveniente provare ad utilizzare un kernel un attimo più personalizzato e quali siano gli aspetti che "prioritariamente" andrebbero ritoccati (intendo per un uso casalingo del computer, niente cose particolari).

Io nel mio kernel custom (2.6.37.3) ho integrato la patch BFS, la patch BFQ, ho impostato il kernel per farlo diventare low-latency e ho eliminato tutti i driver non appartenenti alla mia macchina. Beh, i risultati sono che ho un kernel che garantisce maggiore fluidità, anche in compilazione. Infatti adesso compilo in -j2 e ho un uso più decente del computer, rispetto al kernel di default.

Mi premeva fare una domanda su un argomento che avevo già proposto poco tempo fa.
Ultimamente ho compilato diversi programmi pacchettizandoli da sorgenti. In relazione a questa operazione, la ricompilazione del kernel ha effetti benefici specie a livello di specifica della CPU?
Mi spiego:
Attualmente il kernel in uso gestisce la mia cpu trattandola immagino come una cpu generica i686.
Nel mio caso ho un "Mobile Pentium4-3.2GHz".
Ecco. Ora dicevo, secondo voi, se io specificassi la voce CONFIG_PENTIUM4, otterrei dei miglioramenti visibili ad occhio a livello di funzionamento generale della macchina? E a livello di compilazione dei pacchetti otterrei dei benefici? Non so, magari dei software più performanti o roba simile?

A quanto ne so io, la scelta Pentium4 è da applicare sui processori i686. Io ad esempio ho un AMD Athlon XP 2400+ i686 e ho scelto Pentium4 come tipo processore. Fino ad ora non ho mai avuto problemi.

Chiedeo perchè avevo letto se non ricordo male di un utente che aveva ricompilato kde (se non sbaglio) e notava incrementi prestazionali notevoli... bene, nella discussione era venuto fuori che il kernel in uso durante la compilazione era stato ricompilato specificando la propria CPU... e aquanto avevo capito quel particolare sarebbe stato importante per spiegare questo incremento prestazionale del software compilato.

Beh l'incremento credo sia soggettivo. Ovviamente un kernel che consuma meno risorse e che ha una configurazione adatta può dare più fluidità ad operazioni più onerose, come una compilazione. Credo comunque che le prestazioni diventino via via più impercettibili a seconda della potenza della macchina.

[masalapianta]

Siccome sto usando il kernel 2.6.33.4-smp di default della 13.1, mi chiedevo quanto fosse utile/conveniente provare ad utilizzare un kernel un attimo più personalizzato

nessuna particolare utilità o convenienza

e quali siano gli aspetti che "prioritariamente" andrebbero ritoccati (intendo per un uso casalingo del computer, niente cose particolari).

nessun aspetto, vivi felice con i precompilati

[pardo]

Dal punto di vista delle prestazioni su desktop "dicono" che contino qualcosa di concreto queste opzioni:
CONFIG_SCHED_AUTOGROUP (<-- aggiunta dal 2.6.38)
CONFIG_PREEMPT
CONFIG_IOSCHED_CFQ

Il preemptible kernel che era passato x la rivoluzione a me nn ha cambiato una mazza sinceramente quando fu introdotto... l'i/o e` una me**a perche` uso la crittografia del filesystem quindi alla fine non lo so, fara` sempre schifo in ogni caso.
L'autogrup invece l'ho messo adesso e devo dire che ho notato un netto miglioramento ma bisogna tenere conto che in questo periodo ho la fotta della virtualizzazione e sto caricando sto cesso di pc con delle cose atroci che normalmente non faccio proprio mai (e ho la cpu senza VT, tra l'altro, x cui virtualbox arranca proprio, se poi tento di avviarci il vsphere dentro -come ho fatto- esce dal pc per menarmi direttamente..).

Il tipo di cpu penso sia impercettibile...

Adesso se non ce l'hai gia` puoi magari provare ad abilitare Ext4 x i filesystem ma anche questo non ti cambia sicuramente la luna se usi il pc x fare le solite 2 boiate.

In generale secondo me se uno ha problemi di prestazioni (cosa che nel 99% gia` di base non c'e` perche` hanno tutti pc megagalattici) di solito si riesce a risolvere con altre soluzioni magari molto piu` banali che non cipollare col kernel.

Poi ci sono altri ciappini che magari vuoi vedere x il discorso del risparmio energetico, te li suggerisce il fighissimo programma powertop (tipo NO_HZ e varie altre).

Nei kernel della distro alcune di queste sono abilitate altre no...

L'idea della localconfig nn ho mai provato ma alla fine secondo me nn e` fondamentale. Voglio dire ti basta prendere la config del generic-smp e controllare quello che ti interessa e lasciare tutto il resto uguale. Alleggerire il kernel di tutto il superfluo x il tuo pc e` la tipica cosa da nerd che si fa x sfizio ma in concreto non ti cambia assolutamente nulla, e` una questione di qualche misero KB in piu` o in meno che stara` a dormire in memoria. Io lo faccio for the lulz ma solo a casa mia, x tutte le cose di lavoro e` molto meglio andare ovunque possibile coi setting predefiniti.

[joe]

Grazie della precisazione. Già Masalapianta aveva dato un responso piuttosto secco in merito circa l'altro aspetto, ovvero:
- compilazione programmi usando un kernel con qualche specifica in più circa il tipo di cpu e simili.
Facciamo un esempio:
1- ho il kernel di default standard senza specifiche particolari circa cpu family ecc.
compio il programma "pippo". E mi creo il pacchetto pippo-1.tgz

2- ho il kernel ricompilato con voci che specificano la cpu family ecc.
compilo pippo e creo il pacchetto pippo-2.tgz

Ok, installo pippo-2.tgz lo provo lo uso un po' ecc. poi lo rimuovo e installo pippo-2.tgz.
Quale gira in modo più performante?

A- la versione 2... perchè? è visibilmente percettibile?
B- sono entrambe identiche... perchè?

Spero d'aver snocciolato meglio il mio dubbio.

[Mario Vanoni]

Uso 2.6.37.3, stasera o domani esce 2.6.37.4.
Tre macchine diverse, stesso .config statico minimale per tutte e tre.
Compilo una sola volta e sposto il kernel sulle tre macchine.

Uso Slackware 12.2 aggiornata con swaret, oggi SeaMonkey 2.0.12.
tre macchine stabili al 100% da anni.

Osservando su una delle macchine dormienti sar 1,
la maggior parte del tempo e` 100% idle,
quindi il kernel ha raggiunto quello che aspirava Ken Colivas.

[slux]

Ok, installo pippo-2.tgz lo provo lo uso un po' ecc. poi lo rimuovo e installo pippo-2.tgz.
Quale gira in modo più performante?

A- la versione 2... perchè? è visibilmente percettibile?
B- sono entrambe identiche... perchè?

I pacchetti sono identici in tutto e per tutto.Il kernel non influisce sul risulato della compilazione,eventualmente sul tempo che impieghi a compilare.Sai che delirio sarebbe?Un pacchetto software che va bene solo con una determinata compilazione del kernel? E chi lo userebbe più linux?
Se vuoi migliorare le prestazioni ( e ne dubito comunque perchè i guadagni sono minimi) devi intervenire sui parametri di compilazione dello Slackbuild(CFLAGS e compagnia bella) e sul compilatore GCC.Per il resto è tutta fuffa.

[metrofox]

Ken Colivas.

LOL

[joe]

Perfetto. Il discorso è chiaro a questo punto.
Mi resta il dubbio su quella vecchia discussione cui avevo accennato... Un utente aveva ricompilato kde e riportava di un notevo incremento di reattività, visibile quindi ad occhio del DE.
Se la ritrovo la rileggo nel casoavessi ricordato male e caso mai ve la linko. Grazie degli interventi, alla prossima

[slux]

Un utente aveva ricompilato kde e riportava di un notevo incremento di reattività, visibile quindi ad occhio del DE

Sicuramente era intervenuto su qualche opzione di compilazione.Il kernel non influisce sul risultato della compilazione.Eventualmente può darti una mano modificare le impostazioni dello scheduler (vedi BFS di Con Kolivas),per eseguire i processi in modo più reattivo,abbassando le latenze.Ma i miglioramenti li vedi a prescindere dalla ricompilazione dei programmi in questo caso.

[Mario Vanoni]

2.6.38 e` veloce quanto il 2.6.37-ck1 o 2.6.37.3,
con SeaMonkey 2.0.12 soggettivamente mi sembra piu` veloce,
il tutto sempre con la stabilissima Slackware 12.2.

[slux]

Offtopic: Ho appena installato anch'io il 2.6.38 e devo dire che non rimpiango particolarmente la patch Kon,anche se devo dire che è presto per fare una valutazione obiettiva.Le finestre di KDE si muovono in modo molto fluido e anche se hai un pò di carico pesante in background,il sistema è ancora molto reattivo.Sembra riuscito bene questo kernel.

[erio]

sul 2.6.38 ma bisogna dare yes ad autogroup,visto che non se ne parla,o si puo' fare in altro modo,grazie

[slux]

Sì,abiliti autogroup e ricompili.Eventualmente puoi disattivarlo a runtime in /proc.Non ricordo ora la voce ,ma puoi trovarla facilmente su google e forse anche qui.

[Mario Vanoni]

2.6.38 con in .config
CONFIG_EXPERIMENTAL=y
e
CONFIG_CGROUPS=y

fluxbox/seamonkey
sono molto piu` veloci su siti molto carichi!

Controllo con sar 1 su due macchine con HW identiche,
quella, come detto sopra, idle sempre oltre 90%
senza queste modifiche idle spesso sotto il 10%.