Newsgroup: it.comp.os.linux.sys
Titolo: Kernel Preemtive

Ciao a tutti, quali altri kernel sono preemptive oltre a linux 2.6

i kernel 2.4 se applichi l'apposita patch

 i kernel 2.4 se applichi l'apposita patch
:-) si lo so, intendevo quali altri S.O.!

so per certo che il kernel di solaris sia fully preemptive, non conosco 
la situazione degli altri unix commerciali ma immagino che ce l'abbia 
anche hp/ux. ignoro come sia la situazione con i sistemi operativi 
merdasoft.

Davide Corrado ha scritto:

Ho letto solo di solaris (tra le altre cose, solo solaris per
Sparc, non per ix86). Ignoro altre situazioni.
-- 
ciao, Mirco.
[ 
http://hellspawn.dnsalias.net/~mircomir/
 ] [ Icq#:51640305 ]
[ 
http://pido2.webhop.net/
 ]

Davide Corrado ha scritto:

Ovviamente anche windows è fully preemptive (e da un bel pò)
Su solaris si può scegliere di compilare il kernel "cooperativo"? 
(sempre che si possa compilare il kernel di solaris...)

 Ovviamente anche windows č fully preemptive (e da un bel pņ)
ma dai? davvero?
sara` anche vero, ma, lavorando tutto il gg sotto wincess 2k (sono programmatore
VC) ti garantisco che fa proprio schifo. Non so per quale motivo ma sono sempre
ad attendere che mi ridia il controllo :-)
Cosa che ovviamente non avviene con la mia debian K2.4.24 e premptive patch.
Sara` una bufala come il tanto decantato "microkernel" che NT 4 doveva avere
secondo tutte le riviste del '96? Mah...


 ma dai? davvero?
Secondo me c'e` stata un po' di confusione.
Il kernel di Windows e` preemptive. Non credo sia preemptible come il 2.6.
Il kernel 2.4 (e anche lo 0.01) di Linux sono preemptive ma non
preemptible.
WNT e derivati sono microkernel, quindi non ha poi tantissimo senso
parlare di kernel preemptible. Sono i moduli che devono esserlo, e li` non
saprei proprio se lo sono o meno, e che grado di granularita` abbiano o
come vengano gestiti.
Bye.

 preemptible.
c'e` un patch per renderlo tale.


 
aspetta un attimo: preemptive e preemptible non vogliono dire la stessa 
cosa (si possono "interrompere" i processi in kernel mode)?
grazie e scusate la richiesta...
ciao
LEO


Il kernel, se è preempitible vuol dire che è interrompibile; se è 
preempitive vuol dire che gestisce i processi in modo non cooperativo ma 
comanda lui.
Domanda: quante castronerie sono riuscito a dire in 3 righe?
-- 
Roberto Tagliaferri-Linux user #30785 <-> r.tagliaferri@(forse)
tosnet.it
	(Seen on TV!!!)
	"Risparmiamo 5 centesimi a transazione!"

 Domanda: quante castronerie sono riuscito a dire in 3 righe?
Credo nessuna: AFAIR e' cosi'. Preemptive significa che il kernel 
interrompe i processi quando gli fa comodo e se li giostra in base ai 
propri comodi, preemptiBLE significa che il kernel stesso puo' essere 
interrotto... non e' proprio una cosa banale, tra l'altro.
Per esempio (stupidino e incompleto): se il kernel lancia una lettura da 
un disco e questo (di solito per problemi hardware) non risponde se non 
e' preempbible ottieni un sistema fermo almeno fino al timeout (se il 
timeout c'e'), altrimenti devi pigiare forte il tasto di accensione per 
N secondi ^____^.
-- 
Renato Ramonda
_______________________________
Togli TOGLIMI se vuoi scrivermi

Renato Ramonda ha scritto:

quindi: linux --> NO preemptive ma possibilità di preemptiBLE
	windows --> preemptive e preemptible
Quindi la maggiore risposta di esecuzione che si ha l'impressione di 
avere con windows è dovuta al preemptive?

 avere con windows è dovuta al preemptive?
No, al fatto che la grafica NON e' double buffered, NON ha 
l'antialiasing, NON supporta la grafica vettoriale, e soprattutto e' 
integrata nel Kernel e gira nel cosiddetto (afair) ring-0, cioe' a 
priorita' assoluta, come se fosse il kernel stesso. In pratica ti sta 
fregando: per permettere alla grafica di essere piu' veloce magari ti 
sta ciucciando cicli di cpu ai servizi, che poi DOVREBBERO essere il 
vero scopo di esistere di un server, o no?


 avere con windows è dovuta al preemptive?
Da quello che sapevo io (preistoria):
Win 95: cooperative per prg windows e preempitive per prg dos (!!!)
win nt e seguenti: preempitive
Linux 1.x,2.[0..4] preempitive
Linux 2.6 preempitive e preempitible
La scattosità di windows è dovuta a :
win 9x o me: non sono pensati in nessun modo alla sicurezza (niente 
utenti, permessi ecc)
win nt e seguenti: molti trucchi sporchi (es driver video messi in posti 
innominabili); va tenuto conto anche che XFree è un server, non un banale 
driver video e quindi ha prestazioni per forza di cose inferiori e 
oltretutto non ci sono (o quasi) driver supportati direttamente dalle case 
madri: vuoi mettere un bel driver sviluppato e mantenuto dal chipmaker?


 avere con windows...
ah, si... tu hai questa sensazione quando usi windows?
Io l'esatto contrario...


avere con windows č dovuta al preemptive?
Tipo quando utilizzi il floppy? ;-)


ok, ok, non sono scemo :-) sono d'accordo con voi, solo che anche linux 
(in modalitą grafica) spessissimo mi da degli impuntamenti di questo 
tipo: sto ascoltando mp3, apro openoffice e l'mp3 comincia a "saltare", 
caxxo, con windows non mi era mai successo (dico "era" perchč sono 3 
anni che uso varie distro linux sul mio desktop)
ciao
LEO

 PreemptiBLE... non so, lo e' veramente? io non credo.
Non lo sa nessuno... :-)
bye,
-- 
   Piergiorgio Sartor

 tipo: sto ascoltando mp3, apro openoffice e l'mp3 comincia a "saltare", 
a me non e` mai successo con applicazioni normali...
solo cdrdao leggendo cs in paranoia mode 3 mi rendeva scattoso il desktop
(applicando la patch preemptible kernel le cose sono molto migliorate!)


 anni che uso varie distro linux sul mio desktop)
Questo credo sia dovuto a priorita` di processo degli IRQ o magari di
mancanza del DMA sul disco.
Sui 2.4 puo` essere dovuto anche alla mancanza di preemptible kernel.
Mi spiego.
Se la scheda audio ha IRQ con priorita` inferiore al disco, quando la CPU
attende il disco non processa gli irq della scheda audio e non si accorge
che il suo buffer si e` svuotato. Se la scheda ha buffer misero e non ha
DMA scatta parecchio. Se la scheda ha un buffer buono e magari DMA
(supportato) non dovresti nemmeno accorgertene. Al limite aumenta il
buffer su xmms.
Se sul disco non e` attivo il DMA, la CPU manda il comando di lettura di
un blocco, prende uno per uno i byte dal disco e li sposta in memoria.
Se c'e` il DMA, la CPU manda il comando di lettura e una locazione di
memoria. Il disco sposta i dati in RAM e poi lancia un irq alla CPU. Nel
primo caso hai la CPU al 100%, nel secondo magari al 20%. Quindi nel primo
caso puo` darsi che non ce la faccia a decodificare l'mp3 in tempo,
perche` il kernel ha priorita` maggiore di qualsiasi processo utente.
Con il preemptible, il kernel puo` essere interrotto per processi
interattivi, ma se sbaglia a capire quale sia il processo interattivo,
puo` capitare che salti l'mp3. Hanno gia` provato (credo) una decina di
algoritmi diversi per determinare i processi interattivi, e non credo
abbiano ancora raggiunto la perfezione. Forse l'ideale sarebbe una syscall
che autodichiara chi la usa come interattivo, ma potrebbe essere abusata.
Mah, vedremo..
Fine delirio. :)

 Non lo sa nessuno... :-)
Parlando di NT, se e` veramente microkernel, tutto e` un processo,
compresi i driver, e solo lo scheduler e le code messaggi sono kernel.
Per questo dicevo di non sapere se fosse il caso di parlare di preemptible.
In teoria con questa architettura e` preemptible, perche` essendo normali
processi, possono essere interrotti dal kernel (lo scheduler) in qualsiasi
momento.
Cio` non toglie che per esigenze hardware potrebbero aver implementato una
syscall che disattiva lo scheduler (sull'Amiga era Forbid(), con Permit()
per riattivarlo), e questo spiegherebbe i blocchi irreparabili: Chiamo
Forbid(), faccio un "while (1) {}" e dopo un Permit() che non verra` mai
raggiunto... Probabilmente con gli XP stanno limitando la portata di
queste chiamate e si pianta meno, o magari lo scheduler non puo` piu`
essere interrotto massicciamente ma solo rallentato... chilosa`. :)
Bye.

>  Non lo sa nessuno... :-)
AP> Parlando di NT, se e` veramente microkernel, tutto e` un processo,
AP> compresi i driver, e solo lo scheduler e le code messaggi sono
AP> kernel.
E' tutto uno scambiarsi di messaggi, + o -. "Scusi, task tal dei tali,
con questo messaggio le facciamo cortese richiesta di terminazione"...
Arridatece er kill -9!!!!!
AP> In teoria con questa architettura e` preemptible,
AP> perche` essendo normali processi, possono essere interrotti dal
AP> kernel (lo scheduler) in qualsiasi momento.
L'e` che  ci sono 32 livelli  di priorita` in round  robin, e fintanto
che al livello n c'e`  qualcuno ready, quelli sotto possono crepare di
fame.
Se poi gli e` scappato  dentro l'algoritmo di risveglio e prelievo dei
messaggi  di NT4  e precedenti  ... In  un libro  Microsoft  Press era
definito madness  e si evinceva  chiaramente che era una  direttiva di
quelli del marketing.
 /\            ___
/___/\__|_|\_|__|___Gian Uberto Lauri_____________________
  //--\ | | \|  |   Integralista GNUslamico e fancazzista 
\/