kernel 2.6.26 rilasciato

[targzeta]

Me la suono e me la canto....

E' simpatico leggere i tuoi post, che poi sono quelli più in-topic, in mezzo a tutti questi discorsi "aulici". Non so come spiegarti l'immagine che mi viene alla mente, tutti immersi in questa discussione a cercare di capire, spiegare, farsi capire, e poi tu che alzi la manina e chiedi informazioni normali, in linea con il topic. Mi fa veramente ridere di cuore .
Ma tornando a te, visto che nel file local abiliti semplicemente il governor "ondemand", non ti converrebbe abilitarlo di default nel kernel? Tanto quello che fai tu è di impostare il governor userspace, e poi impostare quello ondemand all'avvio della macchina. Puoi sempre switchare da un governor all'altro tramite il tuo programma o via filesystem sys, quello che ti da in più il governor userspace è la possibilità di settare da te la frequenza della CPU, cosa che negli altri governor viene gestita automaticamente.

Forse questo link potrebbe interessarti:
http://softwarecommunity.intel.com/arti ... g/1611.htm

Spina

[masalapianta]

premetto l'intenzione di non voler fare polemica, pero' posso riportare la mia esperienza (parolone )
anch'io ho lavorato/lavoro in ambiente enterprise e, nonostante le argomentazioni poste, a volte abbiamo preferito un kernel statico (variamente ottimizzato, ridotto, corazzato, ecc.) per:
- macchine multiutente con utenti supersmanettoni
- router/bridge
- macchine dedicate al calcolo scientifico
- tuning per situazioni particolari (grosso i/o, responsivita', ecc.)

potrei sapere che vantaggi vedi in un kernel monolitico rispetto a un modulare (perche' con tutta la buona volonta' del mondo personalmente vedo solo svantaggi)

il tempo di ricompilazione dell'intero kernel o alternativamente del modulo (elemento di discrimine tra la scelta statico/modulare, nel ragionamento,

no, lo ripeto:
nel caso del monolitico ricompili centinaia di kernel, nel caso del modulare ne devi ricompilare solo tanti quante sono le architetture di cui disponi (il 99% delle volte meno di una decina); non e' esattamente la stessa cosa in termini di tempo

comunque e' necessario il reboot (scordandoci kexec) non e' poi cosi' rilevante come un tempo (ora, al peggio, e' questione di pochissimi minuti),

il problema non e' tanto il tempo di compilazione, ma i comandi per la ricompilazione che non puoi dare in parallelo (vedi sotto)

e ci sono strumenti come pconsole che permettono di lavorare agevolmente in parallelo su molte macchine.

pconsole o affini lo puoi usare solo quando i comandi da dare son gli stessi (se ti organizzi bene utilizzando gli stessi path su tutte le macchine puoi lanciare in parallelo make bzImage, l'mv dell'image e pochissimo altro, ma il make oldconfig (che e' quello che porta via maggior tempo) te lo scordi di darlo via pconsole; il che se hai centinaia di macchine si traduce in tempi di aggiornamento enormi)

come ho detto prima, situazioni e punti di vista diversi, anche in ambiente enterprise.

permettimi un po di scetticismo, non so dove hai lavorato e che dimensione avesse il parco macchine che gestivi ma in tanti anni ho girato molti dei ced piu' grandi d'Italia (pomezia, rozzano, oriolo, ecc..) e visto anche qualcosa all'estero, e mai, dico _mai_, ho visto utilizzare kernel statici se non su singole macchine gestite direttamente dal cliente che, essendo evidentemente ignorante in materia, riteneva che un kernel statico desse qualche tipo di vantaggio

P.S. probabilmente non sono stato chiaro, pero' ribadisco che non parliamo di qualche decina di macchine (dove quel che dici, con qualche accortezza, puo' anche essere fattibile) ma di qualche centinaio

[masalapianta]

Essendo situati in una intranet (anche se mooolto grossa), normalmente inaccessibile dall'esterno, non faccio neanche
gli aggiornamenti di sicurezza.

questo e' male, considera che statisticamente la maggior parte degli attachi avviene dalla rete interna; gli aggiornamenti di sicurezza andrebbero sempre fatti (a meno di macchine scollegate dalla rete, utilizzate da una singola persona e su cui non viene eseguito, installato codice nuovo)

[ponce]

premetto l'intenzione di non voler fare polemica, pero' posso riportare la mia esperienza (parolone )
anch'io ho lavorato/lavoro in ambiente enterprise e, nonostante le argomentazioni poste, a volte abbiamo preferito un kernel statico (variamente ottimizzato, ridotto, corazzato, ecc.) per:
- macchine multiutente con utenti supersmanettoni
- router/bridge
- macchine dedicate al calcolo scientifico
- tuning per situazioni particolari (grosso i/o, responsivita', ecc.)

potrei sapere che vantaggi vedi in un kernel monolitico rispetto a un modulare (perche' con tutta la buona volonta' del mondo personalmente vedo solo svantaggi)

e' piu' performante e scattante (a volte e' essenziale che lo sia).

il tempo di ricompilazione dell'intero kernel o alternativamente del modulo (elemento di discrimine tra la scelta statico/modulare, nel ragionamento,

no, lo ripeto:
nel caso del monolitico ricompili centinaia di kernel, nel caso del modulare ne devi ricompilare solo tanti quante sono le architetture di cui disponi (il 99% delle volte meno di una decina); non e' esattamente la stessa cosa in termini di tempo

nel caso del monolitico difficilmente nelle situazioni descritte ho avuto bisogno di ricompilare centinaia di kernel perche' nel 99% dei casi mi trovo a lavorare con stock di hardware, sia per le workstation che per i server.

comunque e' necessario il reboot (scordandoci kexec) non e' poi cosi' rilevante come un tempo (ora, al peggio, e' questione di pochissimi minuti),

il problema non e' tanto il tempo di compilazione, ma i comandi per la ricompilazione che non puoi dare in parallelo (vedi sotto).

patcho i kernel o compilo i moduli, solo se indispensabile cambio la versione.

e ci sono strumenti come pconsole che permettono di lavorare agevolmente in parallelo su molte macchine.

pconsole o affini lo puoi usare solo quando i comandi da dare son gli stessi (se ti organizzi bene utilizzando gli stessi path su tutte le macchine puoi lanciare in parallelo make bzImage, l'mv dell'image e pochissimo altro, ma il make oldconfig (che e' quello che porta via maggior tempo) te lo scordi di darlo via pconsole; il che se hai centinaia di macchine si traduce in tempi di aggiornamento enormi)

considerate le premesse di cui sopra penso di aver gia' risposto.

come ho detto prima, situazioni e punti di vista diversi, anche in ambiente enterprise.

permettimi un po di scetticismo, non so dove hai lavorato e che dimensione avesse il parco macchine che gestivi ma in tanti anni ho girato piu' o meno molti dei ced piu' grandi d'Italia (pomezia, rozzano, oriolo, ecc..) e visto anche qualcosa all'estero, e mai, dico _mai_, ho visto utilizzare kernel statici se non su singole macchine gestite direttamente dal cliente che, essendo evidentemente ignorante in materia, riteneva che un kernel statico desse qualche tipo di vantaggio

ced e strutture che offrono servizi a Universita' (o Scuole di Eccellenza) o all'interno di stabilimenti con migliaia di utenti, geograficamente distribuiti (intendendo utenti, ced e attrezzature)

P.S. probabilmente non sono stato chiaro, pero' ribadisco che non parliamo di qualche decina di macchine (dove quel che dici, con qualche accortezza, puo' anche essere fattibile) ma di qualche centinaio

forse anch'io sono stato poco chiaro: non uso SEMPRE kernel monolitici, pero' in determinate situazioni ha senso usarli.

[aschenaz]

Essendo situati in una intranet (anche se mooolto grossa), normalmente inaccessibile dall'esterno, non faccio neanche
gli aggiornamenti di sicurezza.

questo e' male, considera che statisticamente la maggior parte degli attachi avviene dalla rete interna; gli aggiornamenti di sicurezza andrebbero sempre fatti (a meno di macchine scollegate dalla rete, utilizzate da una singola persona e su cui non viene eseguito, installato codice nuovo)

Si, lo so, finora sono stato fortunato...
Ma gli aggiornamenti di sicurezza vengono rilasciati anche per le precedenti
release? Aggiornando con i pacchetti che trovo in patches, dovrei quindi
stare tranquillo?
Altrimenti, per stare al passo, dovrei aggiornare anche il sistema...

[gioco]

Ma gli aggiornamenti di sicurezza vengono rilasciati anche per le precedenti
release?

Sì:
ftp://slackware.osuosl.org/pub/slackwar ... ngeLog.txt

[aschenaz]

Ma gli aggiornamenti di sicurezza vengono rilasciati anche per le precedenti
release?

Sì:
ftp://slackware.osuosl.org/pub/slackwar ... ngeLog.txt

Ok, grazie 1000!

[masalapianta]

potrei sapere che vantaggi vedi in un kernel monolitico rispetto a un modulare (perche' con tutta la buona volonta' del mondo personalmente vedo solo svantaggi)

e' piu' performante e scattante.

hai fatto dei benchmark (che non siano "a occhio mi pare che..")? l'overhead dovuto all'uso dei moduli e' praticamente irrilevante su macchine moderne; considera che parliamo di un monolitico modulare (anche se ultimamente sono state fatte modifiche per renderlo ibrido, ma ad oggi, il 99% della roba continua a girare in kernel space) e non un microkernel, quindi anche con l'uso dei moduli non c'e' scambio di messaggi e relativo context switch (fonte di rilevante overhead) e l'overhead resta trascurabile

no, lo ripeto:
nel caso del monolitico ricompili centinaia di kernel, nel caso del modulare ne devi ricompilare solo tanti quante sono le architetture di cui disponi (il 99% delle volte meno di una decina); non e' esattamente la stessa cosa in termini di tempo

nel caso del monolitico difficilmente nelle situazioni descritte ho avuto bisogno di ricompilare centinaia di kernel perche' nel 99% dei casi mi trovo a lavorare con stock di hardware, sia per le workstation che per i server.

se ne deduce che la tua e' una situazione atipica e statisticamente irrilevante, normalmente nei ced i parco macchine sono assolutamente eterogenei

il problema non e' tanto il tempo di compilazione, ma i comandi per la ricompilazione che non puoi dare in parallelo (vedi sotto)

patcho i kernel o compilo i moduli, solo se indispensabile cambio la versione.

almeno su questo (non aggiornare la release se non indispensabile) siamo daccordo

permettimi un po di scetticismo, non so dove hai lavorato e che dimensione avesse il parco macchine che gestivi ma in tanti anni ho girato piu' o meno molti dei ced piu' grandi d'Italia (pomezia, rozzano, oriolo, ecc..) e visto anche qualcosa all'estero, e mai, dico _mai_, ho visto utilizzare kernel statici se non su singole macchine gestite direttamente dal cliente che, essendo evidentemente ignorante in materia, riteneva che un kernel statico desse qualche tipo di vantaggio

ced che offrono servizi a Universita' (o Scuole di Eccellenza) e di stabilimenti con migliaia di utenti, geograficamente distribuiti.

me l'ero immaginato, quindi una situazione atipica (una delle poche dove il parco macchine non e' molto eterogeneo; avevo gia citato ced dedicati per calcolo parallelo e render farm dove il parco macchine e' assolutamente omogeneo, la tua situazione invece sta nel mezzo); in questi casi, con un parco macchine abbastanza omogeneo puoi effettivamente permetterti certe cose (anche se ribadisco che non ha molto senso in quanto kernel statici non offrono reali vantaggi), ma son casi particolari e non la norma

P.S. probabilmente non sono stato chiaro, pero' ribadisco che non parliamo di qualche decina di macchine (dove quel che dici, con qualche accortezza, puo' anche essere fattibile) ma di qualche centinaio

forse anch'io sono stato poco chiaro: non uso SEMPRE kernel monolitici, pero' in determinate situazioni ha senso usarli.

ok, rimango dell'idea che non abbia mai senso usarli, ma prendo atto del fatto che lo fai in situazioni particolari (nella mia risposta precedente avevo inteso che era una regola e non un'eccezione)

[sperelli]

Me la suono e me la canto....

E' simpatico leggere i tuoi post, che poi sono quelli più in-topic, in mezzo a tutti questi discorsi "aulici". Non so come spiegarti l'immagine che mi viene alla mente, tutti immersi in questa discussione a cercare di capire, spiegare, farsi capire, e poi tu che alzi la manina e chiedi informazioni normali, in linea con il topic. Mi fa veramente ridere di cuore .
Ma tornando a te, visto che nel file local abiliti semplicemente il governor "ondemand", non ti converrebbe abilitarlo di default nel kernel? Tanto quello che fai tu è di impostare il governor userspace, e poi impostare quello ondemand all'avvio della macchina. Puoi sempre switchare da un governor all'altro tramite il tuo programma o via filesystem sys, quello che ti da in più il governor userspace è la possibilità di settare da te la frequenza della CPU, cosa che negli altri governor viene gestita automaticamente.

Forse questo link potrebbe interessarti:
http://softwarecommunity.intel.com/arti ... g/1611.htm

Spina

Un po' come un bambino che coi i suoi perché? disturba i "grandi" impegnati in discorsi fuori dalla sua portata.

Ad ogni modo, ho provato a ricompilare il kernel con governor ondemand ma poi ricevevo un errore tentanto di caricare il modulo acpi-cpufreq. Pertanto sono tornato indietro.

ciao

[masalapianta]

Essendo situati in una intranet (anche se mooolto grossa), normalmente inaccessibile dall'esterno, non faccio neanche
gli aggiornamenti di sicurezza.

questo e' male, considera che statisticamente la maggior parte degli attachi avviene dalla rete interna; gli aggiornamenti di sicurezza andrebbero sempre fatti (a meno di macchine scollegate dalla rete, utilizzate da una singola persona e su cui non viene eseguito, installato codice nuovo)

Si, lo so, finora sono stato fortunato...
Ma gli aggiornamenti di sicurezza vengono rilasciati anche per le precedenti
release?

se intendi le release della distribuzione: fintanto che la release in uso resta supportata, si (poi va fatto un upgrade della release )

Aggiornando con i pacchetti che trovo in patches, dovrei quindi
stare tranquillo?

non sei mai tranquillo, la sicurezza non e' un insieme di task ma un processo in continua evoluzione, cui bisogna stare sempre appresso per poter tendere (ma mai raggiungere) a qualcosa di sicuro

Altrimenti, per stare al passo, dovrei aggiornare anche il sistema...

inutile, fintanto che per la release in uso vengono rilasciati gli aggiornamenti

[targzeta]

...Ad ogni modo, ho provato a ricompilare il kernel con governor ondemand ma poi ricevevo un errore tentanto di caricare il modulo acpi-cpufreq. Pertanto sono tornato indietro....

Bhé, sarebbe interessante capire perchè non ti funziona. Ma forse mi sono espresso male io, nel menù del 'CPU frequency scaling' dovresti abilitare i governor e poi impostare di default quello ondemand, o conservative, alla voce 'Default CPUFreq governor'

Spina

[ponce]

potrei sapere che vantaggi vedi in un kernel monolitico rispetto a un modulare (perche' con tutta la buona volonta' del mondo personalmente vedo solo svantaggi)

e' piu' performante e scattante.

hai fatto dei benchmark (che non siano "a occhio mi pare che..")? l'overhead dovuto all'uso dei moduli e' praticamente irrilevante su macchine moderne; considera che parliamo di un monolitico modulare (anche se ultimamente sono state fatte modifiche per renderlo ibrido, ma ad oggi, il 99% della roba continua a girare in kernel space) e non un microkernel, quindi anche con l'uso dei moduli non c'e' scambio di messaggi e relativo context switch (fonte di rilevante overhead) e l'overhead resta trascurabile

si, e il guadagno c'e': non vorrei mettermi pero' a disquisire di benchmark con bonnie o menate simili
su queste cose si e' scannata gente ben piu' grossa di me.
comunque chiunque puo' provare il throughput su un router/bridge con netfilter statico o un mysql statico su un kernel a sua volta statico.

no, lo ripeto:
nel caso del monolitico ricompili centinaia di kernel, nel caso del modulare ne devi ricompilare solo tanti quante sono le architetture di cui disponi (il 99% delle volte meno di una decina); non e' esattamente la stessa cosa in termini di tempo

nel caso del monolitico difficilmente nelle situazioni descritte ho avuto bisogno di ricompilare centinaia di kernel perche' nel 99% dei casi mi trovo a lavorare con stock di hardware, sia per le workstation che per i server.

se ne deduce che la tua e' una situazione atipica e statisticamente irrilevante, normalmente nei ced i parco macchine sono assolutamente eterogenei

era per dire che magari ci sono 5/10 server uguali, 20 macchine di un cluster uguali, 100 workstation uguali, quindi il numero di kernel da ricompilare si riduce drasticamente.

[sperelli]

Bhé, sarebbe interessante capire perchè non ti funziona. Ma forse mi sono espresso male io, nel menù del 'CPU frequency scaling' dovresti abilitare i governor e poi impostare di default quello ondemand, o conservative, alla voce 'Default CPUFreq governor'

Spina

E' proprio quello che ho fatto, la pena, l'impossibilità di caricare acpi-cpufreq. Vabbè, se ne riparlerà col prossimo kernel. Intanto, grazie per i consigli.

[masalapianta]

hai fatto dei benchmark (che non siano "a occhio mi pare che..")? l'overhead dovuto all'uso dei moduli e' praticamente irrilevante su macchine moderne; considera che parliamo di un monolitico modulare (anche se ultimamente sono state fatte modifiche per renderlo ibrido, ma ad oggi, il 99% della roba continua a girare in kernel space) e non un microkernel, quindi anche con l'uso dei moduli non c'e' scambio di messaggi e relativo context switch (fonte di rilevante overhead) e l'overhead resta trascurabile

si, e il guadagno c'e': non vorrei mettermi pero' a disquisire di benchmark con bonnie o menate simili
su queste cose si e' scannata gente ben piu' grossa di me.
comunque chiunque puo' provare il throughput su un router/bridge con netfilter statico o un mysql statico su un kernel a sua volta statico.

permettimi di essere nuovamente scettico, ma tempo fa feci anche io dei test, con sistemi di benchmark standard (bonnie e compagnia cantante) e qualcosa di piu' mirato (kprobes per collezionare statistiche su routine del kernel prima compilate statiche e poi in moduli; questo permette di avere la reale misura delle differenze di overhead tra una routine compilata statica o in un modulo, laddove con benchmark standard entrano in ballo altri fattori) e, su hardware di fascia bassa (biprocessore xeon), le differenze erano trascurabili (per caso, nel test che hai fatto, come modulare hai utilizzato un precompilato non ottimizzato per la tua architettura?)

se ne deduce che la tua e' una situazione atipica e statisticamente irrilevante, normalmente nei ced i parco macchine sono assolutamente eterogenei

era per dire che magari ci sono 5/10 server uguali, 20 macchine di un cluster uguali, 100 workstation uguali, quindi il numero di kernel da ricompilare si riduce drasticamente.

si, ma ripeto che la tua situazione e' atipica, mediamente in un ced non ci sono "20 macchine in cluster uguali", ecc.. (mediamente trovi 4/5 macchine uguali in bilanciamento, 2 o 3 macchine uguali in alta affidabilita', ecc..), ma in generale il parco macchine e' moooolto piu' eterogeneo (e i kernel da ricompilare diventano tantissimi)

[Mario Vanoni]

Essendo situati in una intranet (anche se mooolto grossa), normalmente inaccessibile dall'esterno, non faccio neanche
gli aggiornamenti di sicurezza.

questo e' male, considera che statisticamente la maggior parte degli attachi avviene dalla rete interna; gli aggiornamenti di sicurezza andrebbero sempre fatti (a meno di macchine scollegate dalla rete, utilizzate da una singola persona e su cui non viene eseguito, installato codice nuovo)

In simili frangenti sussiste un problema:

klogd(8) legge System.map, con kernel statico invariato,
con kernel che carica/scarica moduli rimane confuso.

Secondo la man page con ogni cambio di modulo bisognerebbe chiamare
klogd -i
e/o
klogd -I
e/o
klogd -p

Come governi tu questa situazione?