Quanto è grande il vostro kernel?

[chaosd]

Originariamente inviato da Ikitt
Beh parliamone: da dove nasce codesta convinzione?
In primis: che si intende per "operazioni di multitasking"? Velocita` di context switch? Responsivita` del sistema? Capacita` di sopportazione del carico?

bravo, intendevo questo tipo di prestazioni

però devo spezzare un giavellotto in mio favore: io pensavo che essendo la cache limitata, più il kernel è piccolo, più ne viene caricato (in %) in cache, quindi le prestazioni globali ne avrebbero risentito positivamente

[robyro]

roby:/boot# du -h /boot/linux-2.6.5-3
1.5M /boot/linux-2.6.5-3

[Enrico81]

bash-2.05b$ du -h /boot/vmlinuz
1.3M /boot/vmlinuz
bash-2.05b$

[Ikitt]

Originariamente inviato da chaosd
bravo, intendevo questo tipo di prestazioni

Vediamo... Purtroppo le mie conoscienze di SO non sono cosi` approfondite come dovrebbero essere, comunque,
nella bzImage (cosi` come nei moduli) non e` che ci si mette roba tanto per far volume: quel che c'e`, si presuppone, c'e` perche` serve, quindi se serve deve star in memoria... E se le risorse scarseggiano, o si tira la cinghia (si schiantano dei processi, o si swappano quelli), o si compra altra RAM

Tornando a bomba, nella commutazione di contesto in quanto tale, non vedo come le dimensioni del kernel possano avere una qualche influenza rilevante, dato che
1) la dimensione del codice kernel in quanto tale preposta al context switch non varia
2) la dimensione dei dati (descrittore del processo, mappe della memoria and so on) da salvare/ripristinare non varia.

Responsivita` del sistema: dipende ANCHE dalla dimensione del kernel, ma non solo da quella (per motivi di cache come dici piu` sotto), ma anche da fattori interni quali l'interrompibilita` delle routine di nucleo (preemptible kernel), la latenza delle routine, la bonta` dello scheduler...

La capacita` di sopportazione del carico (scalabilita`) dipende in massima parte dalla bonta` delle routine interne, non tanto dalla dimensione del kernel

però devo spezzare un giavellotto in mio favore: io pensavo che essendo la cache limitata, più il kernel è piccolo, più ne viene caricato (in %) in cache, quindi le prestazioni globali ne avrebbero risentito positivamente

Assunto discutibile.
In cache ci stanno (dovrebbero starci) le pagine che hanno un hit rate da parte del processore piu` alto, ovvero, in soldoni, quelle che contengono codice (e dati) usati piu` di frequente. Le pagine di codice (e dati) usate piu` di frequente, sono quelle relative a task pesanti dal punto di vista computazionale; una delle ragion d'essere del kernel e` quella di "perdere meno tempo possibile", dato che il tempo impiegato in operazioni di sistema e`, in effetti, tempo perso a danno di quello, piu` fruttuoso, impiegato per l'elaborazione utente.
Idealmente (a parte i problemi di prestazioni) le pagine relative al kernel non dovrebbero mai entrare in cache, per evitare di invalidarla (e far perdere tempo al processo utente), e oltretutto per evitare di togliere spazio alle piu` utili pagine utenti.
Tenere le pagine relative al kernel in cache ha senso solo quando quest'ultimo costituisce un rilevante peso computazionale, cosa che, come detto, non dovrebbe succedere mai (infatti quando "top" da una voce troppo alta relativa all'uso di CPU per attivita` di sistema si guarda subito in cerca di problemi )

Bon, l'esposizione, purtroppo, non e` cosi` brillante, ma a mia discolpa dico che son sveglio da poco ...

PS:
per non scivolare troppo OT, ho ricompilato un 2.6.7 (figatissima make-kpkg !), con questi risultati:

$ ls -lh /boot/vmlinuz-2.6.7-1xr-k7
-rw-r--r--  1 root root 984K Aug 12 21:53 /boot/vmlinuz-2.6.7-1xr-k7
$ awk '{ size += $2 } END { print size }' /proc/modules
818304

[arcobalenos]

832 KB

[chaosd]

Originariamente inviato da Ikitt

Idealmente (a parte i problemi di prestazioni) le pagine relative al kernel non dovrebbero mai entrare in cache, per evitare di invalidarla (e far perdere tempo al processo utente), e oltretutto per evitare di togliere spazio alle piu` utili pagine utenti.
Tenere le pagine relative al kernel in cache ha senso solo quando quest'ultimo costituisce un rilevante peso computazionale, cosa che, come detto, non dovrebbe succedere mai
[/code]

complimenti, secondo me hai dato di recente l'esame di informatica 2...
non scherzo, quello che dici mi ha convinto, ma la frase che ho quotato un po' meno, non so dirti esattamente perchè, ma mi serve un motivo più valido per accettare che il kernel in cache è pressochè inutile, o se non altro non così influente


e accidenti, le dimensioni del tuo kernel... sono invidiabili!

[Kamui]

Pesano tutti 1,7M

root(/home/sly) #du -h /boot/vmlinuz-2.6* | awk '{print  $1}'
1,7M
1,7M
1,7M

Ma è tutto monolitico, l'unico modulo è radeon, potrei anche togliere il supporto ai moduli

[adarkar]

Originariamente inviato da chaosd
ma mi serve un motivo più valido per accettare che il kernel in cache è pressochè inutile

a me mi ha convinto..
nel senso non mi sembra per niente strano quel che dice.
il kernel in cache è meglio che non ci stia per non rubare spazio al codice utente che è quello che realmente vogliamo sia eseguito

[Enrico81]

2.6M Kernel base di ArchLinux VVoVe:

[colombre]

enry@bear:~$ ls -l /boot/vmlinuz-2.6.7
-rw-r--r-- 1 root root 2113635 2004-08-12 22:10 /boot/vmlinuz-2.6.7

VVoVe: