slacky.eu

ciao a tutti

dato che sono in current ed utilizzo una configurazione personale del kernel ,in riferimento all'aggiornamento del 19 marzo volevo sapere:
l'unico pacchetto kernel* che devo aggiornare è :

d/kernel-headers-2.6.28.8_smp-x86-1.tgz: Upgraded to Linux 2.6.28.8.

tralasciando gli altri ?

a questo punto dopo un riavvio posso compilare il nuovo kernel con il mio vecchio config?

Anch'io ho un kernel ricompilato e ho solo gli header ufficiali e il pacchetto kernel-firmware (che probabilmente nemmeno mi serve ma non mi da fastidio e lo lascio li)

Comunque non per dire...ma a me pare che i nuovi kernel stiano perdendo in prestazioni!

Feci un benchmark su salckware 12.2 (kernel 2.6.27.7) e trovai questo risultato:
Invece, portando slackware alla current (kernel 2.6.28.7) ho trovato questo risultato:
Ora è vero che il floating point va un po' meglio (un 2% circa), ma è anche vero che l' utilizzo della memoria ha perso circa un 20%, che non mi pare affatto un dato trascurabile...
Ci tengo a precisare che in entrambi i casi il codice è stato compilato senza alcuna ottimizzazione...

zxzxasas ha scritto:Comunque non per dire...ma a me pare che i nuovi kernel stiano perdendo in prestazioni!

Feci un benchmark su salckware 12.2 (kernel 2.6.27.7) e trovai questo risultato:

Codice: Seleziona tutto

==============================LINUX DATA BELOW===============================
CPU                 : Dual AuthenticAMD AMD Sempron(tm) Dual Core Processor TJ-43 1700MHz
L2 Cache            : 256 KB
OS                  : Linux 2.6.27.7-smp
C compiler          : gcc version 4.2.4
libc                : libc-2.7.so
MEMORY INDEX        : 13.058
INTEGER INDEX       : 10.205
FLOATING-POINT INDEX: 18.759
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38

Invece, portando slackware alla current (kernel 2.6.28.7) ho trovato questo risultato:

Codice: Seleziona tutto

==============================LINUX DATA BELOW===============================
CPU                 : Dual AuthenticAMD AMD Sempron(tm) Dual Core Processor TJ-43 1700MHz
L2 Cache            : 256 KB
OS                  : Linux 2.6.28.7-smp
C compiler          : gcc version 4.3.3 (GCC)
libc                : libc-2.9.so
MEMORY INDEX        : 10.542
INTEGER INDEX       : 9.999
FLOATING-POINT INDEX: 19.095
Baseline (LINUX)    : AMD K6/233*, 512 KB L2-cache, gcc 2.7.2.3, libc-5.4.38
* Trademarks are property of their respective holder.

Ora è vero che il floating point va un po' meglio (un 2% circa), ma è anche vero che l' utilizzo della memoria ha perso circa un 20%, che non mi pare affatto un dato trascurabile...
Ci tengo a precisare che in entrambi i casi il codice è stato compilato senza alcuna ottimizzazione...

Domanda: i due kernel come sono stati compilati?

Usando gcc 4.2.4 con l'opzione -O2,
gcc 4.3.3 con l'opzione -Os fa molta differenza.

L'opzione -Os ottimizza a minor codice compilato,
abbastanza ripugnato nella LKML,
non utilizzando/cancellando certi trucchi per velocizzare.

Anche con gcc 4.2.4 l'opzione -Os ha effettivi negativi,
provato di persona, tornato pentito a -O2!

Nel make menuconfig si ha la scelta.

Sono i tgz fatti da Pat...non li ho ricompilati io! per questo pensavo fosse una cosa propria del kernel, non credo che Pat faccia delle grandi modifiche di volta in volta, anche se onestamente l' ignoro!

zxzxasas ha scritto:Sono i tgz fatti da Pat...non li ho ricompilati io! per questo pensavo fosse una cosa propria del kernel, non credo che Pat faccia delle grandi modifiche di volta in volta, anche se onestamente l' ignoro!

Nel .config mio privato
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
opzione -O2
con make menuconfig lo puoi cambiare a
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
opzione -Os

Nel kernel usato dalla 12.2
/boot/config-huge-smp-2.6.27.7-smp
non lo contiene affatto, quindi opzione -O2.

Visto che hai una -current,
posta p.f. quello che PJV ha deciso.

pasquale@darkstar:/boot$ nano config-huge-smp-2.6.28.7-smp

# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set

-O2...

zxzxasas ha scritto:pasquale@darkstar:/boot$ nano config-huge-smp-2.6.28.7-smp

# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set

-O2...

Grazie, sempre nbench statico, kernel statici

Dati del 08-Jan-2009, kernel 2.6.27.??, a due cifre
MEM 14.643
INT 14.568
FP 24.676

Dati di oggi con kernel 2.6.28.8
MEM 14.908
INT 11.113
FP 23.849

Sempre gcc 4.2.4, giudica tu.

Mario Vanoni ha scritto:

zxzxasas ha scritto:pasquale@darkstar:/boot$ nano config-huge-smp-2.6.28.7-smp

# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set

-O2...

Grazie, sempre nbench statico, kernel statici

Dati del 08-Jan-2009, kernel 2.6.27.??, a due cifre
MEM 14.643
INT 14.568
FP 24.676

Dati di oggi con kernel 2.6.28.8
MEM 14.908
INT 11.113
FP 23.849

Sempre gcc 4.2.4, giudica tu.

Direi che anche in questo caso ci sono delle perdite evidenti...
Chissà come mai...

cavoli.. molto interessante sta cosa! Grazie della discussione..

Come effettuate i test?

Vito ha scritto:Come effettuate i test?

nbench...io ho usato la versione 2.2.2 senza ottimizzazioni!

Vito ha scritto:Come effettuate i test?

http://www.tux.org/~mayer/linux/bmark.html

nbench-byte-2.2.3.tar.gz

thread:
mandriva , una scheggia

Ecco il risultato.(nbench compilato "semplicemente" con make)
Sapete dirmi se è buono o no?(ho letto la documentazione ma vorrei un vostro parere)
Inoltre volevo un consiglio : conviene abilitare la voce "Generic x86 Support" quando il mio processore è un Dual Core?(vedi benchmark)
Attualmente l'ho disabilitata.

Il mio kernel è un 2.6.28.8

P.S. Grazie per la segnalazione.

Vito ha scritto: Inoltre volevo un consiglio : conviene abilitare la voce "Generic x86 Support" quando il mio processore è un Dual Core?(vedi benchmark)

intendi nel kernel?
no, perché serve come scritto nella documentazione a far sì che il codice prodotto vada nel maggior numero di CPU, se non devi ridistribuirlo disabilitala pure

il fatto che sia dual core non c'entra niente, quello lo devi settare in altra voce