[Linux-Biella] che distro per P200?
CIARROCCHI, Paolo, VF-IT
linux@ml.bilug.linux.it
Tue, 22 Jun 2004 09:56:54 +0200
From: Marco Ermini [mailto:markoer@markoer.org]
> CIARROCCHI, Paolo, VF-IT disse:
> [...]
> > Un 2.6 e' fully preemptive e lo switch nel menuconfig e' tutto meno
> > che sbagliato.
> [...]
>
> E' sbagliato il significato che gli è stato dato (ed il
> problema, ripeto,
> non è terminologico tra "preempitive" e "preempitable", come
> se usare un
> aggettivo al posto di un sostantivo cambi qualcosa), e la
> citazione che
> hai postato è decontestualizzata e quindi equivoca; in questo
> modo stai
> continuando a perpetrare confusione.
Ho postato una riposta di Robert Love (autore della patch)
alla domanda: "Ci spieghi in cosa consiste la tua patch" ?
Abbi pazienza, ma non mi sembra assolutamente decontestualizzata.
> Il livello di discussione era estremamente meno specifico, molto più
> "terra terra" e non necessariamente collegato ai dettagli
> implementativi
> di Linux.
>
> La distinzione tra kernel preempitive e kernel collaborative
> è quella che
> ho già postato. Leggi la citazione che hai postato tu in
> questo modo: il
> kernel di Linux (fino al 2.4 ma in massima sostanza anche il
> 2.6) non è
> stato pensato per essere un kernel in alcun modo real time, ovvero non
> garantisce un accesso alle risorse hardware entro dei precisi massimi
> tempi di latenza. Quello che Linux fa bene è l'utilizzare
> degli algoritmi
> stabili e provati che garantiscono un accesso di tipo time
> sharing fully
> preempitive alle applicazioni, ma senza garanzie sui tempi di latenza.
> Questo significa che l'unico "direttore di orchestra" che
> sempre gira e
> che non viene mai preempitato è appunto il kernel stesso. E su questo
> siamo tutti d'accordo.
>
> Quello che viene fatto, in più, sul 2.6 è aggiungere la possibilità di
> preempitare anche parti del kernel stesso (che ormai ti
> faccio presente, è
> elefantiaco ed ingloba centinaia e centinaia di moduli):
> questo è utile in
> un'ottica di scalabilità, per esempio su sistemi NUMA con CPU
> hot-swap o
> dove non è in generale possibile fermare il sistema nemmeno
> per aggiornare
> il kernel, oppure è utile per il vendor che volesse creare e
> certificare
> un sistema soft real time, avendo maggiori possibilità di
> controllare e
> misurare i tempi di latenza (i kernel real time basati su
> Linux potranno
> sempre e solo essere partoriti da un vendor che fa un lavoro
> specifico,
> proprio perché Linux per sua natura non lo è, almeno per adesso).
Non sono d'accordo con te.
La patch e' stata sviluppata da Montavista proprio per essere utilizzata
su piccoli sistemi per diminuirne la latemaza media.
> Però questo è un qualcosa in più, un dettaglio ulteriore al discorso
> precedente; deve sempre comunque esistere un processo "1" che comunque
> controlla e dirige i vari "kernel" che vengono preempitati:
> un direttore
> d'orchestra non preempitato (o preempitabile, è lo stesso) deve sempre
> esserci.
>
> Il fatto è che, IMHO, il kernel di Linux è ormai elefantiaco, e quello
> verso cui si sta andando è di far rientrare dalla finestra
> quel concetto
> di microkernel che si è fatto uscire dalla porta - però queste sono
> considerazioni personali ed OT.
Paolo