Newsgroup: it.comp.os.linux.sys
Titolo: Linux & reattivita'

Ciao a tutti,
scrivo per chiarire alcune mie impressioni riguardo questo
S.O. che mi affascina ma, ogni volta che lo utilizzo, mi lascia
perplesso.
PREMESSA:
Questa NON vuol essere l'ennesimo messaggio di flame per
riaprire la diatriba Windows-Linux.
Cio' che diro' sara' COMPLETAMENTE senza nessuna vena
polemica.
Durante un uso "quotidiano" del "Pinguino", ho sempre notato
"qualcosa di strano" che mi portava a tornare ad utilizzare
il s.o. Microsoft.
Ho sempre bazzicato "ambienti" linux ma solo ultimamente
ho fatto "2+2".
Ho letto (su kerneltrap) che sono state sviluppate svariate
patch per "migliorare" lo scheduler.
Ragionandoci un po', la stranezza di Linux (che notavo)
consiste nella sua scarsa reattivita' (ancora + evidente in X).
Un motivo, tra l'altro, per il quale queste persone scrivono
una patch per ridurre la complessita' dello scheduler da O(N)
a O(1) ci sara', no!?
Bene (spero :-D), ora vi scrivo per chiedere QUANTI di voi
utilizzano queste patch e, se, la loro applicazione rende
REALMENTE + "vivace" Linux...quindi (SECONDO ME) piu'
usabile.
Spero di non scatenare l'ennesimo flame...
Grazie.
-- 
Remove _NOSPAM to reply
===> Igor
====> Web Applications' Developer
=====> ICQ UIN: 26472396

Io uso kernel 2.5.X con l'opzione per il preemptible kernel. In effetti 
qualcosa è migliorata, ma non te lo posso quantificare. Per quanto 
riguarda X, è un poco più lento di windows (NT4, che ho sulla stessa 
macchina) per quanto riguarda il panning dele finestre e il disegno 
delle stesse, a volte. Però sotto linux io lavoro con un programma GIS 
che carica bitmap da 100MB in su in pochi secondi. CorelDraw, sotto NT4, 
  con le stesse immagini, sputa l'anima. Quale preferire?
Saluti

 consiste nella sua scarsa reattivita' (ancora + evidente in X).
Ciao omonimo :)
La scarsa reattività che noti credo che sia imputabile più che altro al
desktop manager che utilizzi. D'altro canto non specifichi quali
distribuzioni hai provato, le versioni e il software utilizzato. Facile che
tu usi gnome o kde, ultime versioni. Entrambi non sono esattamente dei pesi
piuma. Considera inoltre che X sotto linux è un processo come un altro e che
in più implementa la struttura client/server. Aggiungi inoltre che
probabilmente stai utilizzando i drivers di default della sceda video e che
se hai una scheda (ad esempio) nvidia puoi scaricarti i driver dal sito del
produttore, ti assicuro che la differenza si nota.
Infine, col mio attuale PC se metto a confronto basandomi sulla reattività
redhat 7.2 + gnome o kde e windows xp direi che l'ago della bilancia pende
in favore di redhat (con i drivers nvidia). Ovvio che se metti a confronto
windows 98 (anche qui non hai specificato quale so Microsoft) con una delle
ultime distribuzioni linux+gnome o kde non c'è paragone in quando a velocità
dell'ambiente grafico, ma non puoi nemmeno paragonare win9x ad un sistema
operativo serio come linux.

 linux.
 
Non puoi nemmeno paragonare win9x a un sistema operativo serio e basta :D

 usabile.
dimmi quali patch per cosa, poi cerco di capire!
c'è uno scheduler nel kernel?
:-)
boh?
ciao

 a O(1) ci sara', no!?
Cos'e` N?
bye,
-- 
  Piergiorgio Sartor

c'è uno scheduler nel kernel?
evabbe`...
-- 
Maurizio - Tannoiser - Lemmo
STIGE Srl Servizi Informatici
Founder Member of ERLUG (Emilia Romagna Linux User Group)
http://erlug.linux.it

 precise o su sistemi di _grandi_ dimensioni (calcolo parallelo, ecc..).
Beh... dall'intervista che ho letto su linux & c., non sembrava proprio 
cosi 'non percepibile' a occhio nudo...
E da come l'ha descritta, lo penso pure io.
Cmq, occorrerebbe provarla, per ora sono troppo niubbo per cimentarmi in 
queste cose :-)
-- 
Sostituire la IXS con sztrash per avere la mia email

queste cose :-)
Un po` di gente l'ha provata. Funziona. Il che non mi pare poco.
Ma il concetto "a occhio nudo", insomma...
Il punto e` che e` molto piu` "percettibile" utilizzare galeon al posto
di mozilla (per dire...).
Apppunto, proporzioni.


Nemo wrote:

Okkio: gli scheduler sono 2, nel caso di linux: uno per lo user space e 
uno per il kernel space.
Quello in user-space è già preemptible praticamente da sempre, mentre 
quello in kernel space ancora non lo è. La patch di love è indubbiamente 
un primo passo verso il passaggio ad uno scheduler preemptive anche in 
kernel-space, ma _molto_difficilmente_ potrete avere aumenti di 
prestazioni considerevoli (o anche solo misurabili) fino a quando la 
maggior parte dei vostri processi gira in user-space.
Porta invece a significativi vantaggi nel momento in cui avete un 
sistema che fa un uso molto pesante dei kernel threads, ed è soggetto ad 
input/output molto pesante. Va da sè che nel caso in cui l'utilizzo del 
sistema, anche se di tipo "desktop", stressa il sistema parecchio, 
allora le misurazioni si fanno percepibili, soprattutto per quanto 
riguarda la "fluidità" alla quale le cose vi vengono presentate (anzi, 
praticamente solo questo... :-)
In pratica: _vi_sembra_ andare meglio... :-)
Esempio: applicazioni multimediali e simili, dove i kernel threads 
roteano a velocità vorticose.
Cito lo stesso Love:
<quote>
I'll start with a quick explanation of how the patch works. Right now, 
the kernel is not preemptible. This means that code running in the 
kernel runs until completion, which is the source of our latency. 
Although kernel code is well written and regulated, the net result is 
that we effectively have an unbounded limit on how long we spend in the 
kernel. Time spent in kernel mode can grow to many hundreds of 
milliseconds. With some tasks demanding sub-5ms latencies, this 
non-preemptibility is a problem.
The preemptible kernel patch changes all this. It makes the kernel 
preemptible, just like userspace. If a higher priority task becomes 
runnable, the preempt patch will allow it to run. Wherever it is. We can 
preempt anywhere, subject to SMP (symmetric multi-processing) locking 
constraints. That is, we use spinlocks as markers for regions of 
preemptibility. Of course, on UP (uni-processing) they aren't actually 
spinlocks, just markers.
The improvement to response is clear: a high priority task can run as 
soon as it needs to. This is a requisite of real-time computing, where 
you need your RT task to run the moment it becomes runnable. But the 
same effect applies to normal interactive tasks: as soon as an event 
occurs (such as the user clicking the mouse) that marks it runnable, it 
can run (subject to the non-preemptible regions, of course).
There are some counterarguments. The first is that the preemptible 
kernel lowers throughput since it introduces complexity. Testing has 
showed, however, that it improves throughput in nearly all situations. 
My hypothesis is that the same quicker response to events that helps 
interactivity helps throughput. When I/O data becomes available and a 
task can be removed from a wait queue and continue doing I/O, the 
preemptible kernel allows it to happen immediately -- as soon as the 
interrupt that set need_resched returns, in fact. This means better 
multitasking.
There are other issues, too. We have to take care of per-CPU variables, 
now. In an SMP kernel, per-CPU variables are "implicitly locked" -- they 
don't have explicit locks but since they are unique to each CPU, a task 
on another CPU can't touch them. Preemption makes it an issue since a 
preempted task can trample on the variables without locks.
Overall I think the issues can be addressed and we can have a 
preemptible kernel as a proper solution to latency in the kernel.
</quote>
Per infos: 
http://kpreempt.sourceforge.net/
Ci trovate anche dei benchmark fatti sullo streaming audio...
Inoltre, l'articolo da cui ho citato:
http://www.linuxdevices.com/articles/AT8267298734.html
-- 
Emanuele "SKULL" Balla
----------------------------------------------------------------------
"How should I know if it works?  That's what beta testers are for. I 
only coded it." (Attributed to Linus Torvalds, somewhere in a posting)

utilizzano queste patch
Ecco la patch:
Modifica il valore di HZ in /usr/src/linux/asm/param.h, incrementandolo.
In alternativa riduci il valore di DEF_PRIORITY in sched.h
-- 
Per rispondermi, ricordati di togliere il 
nome del poeta e il trattino.

 In alternativa riduci il valore di DEF_PRIORITY in sched.h
Ok...FORSE l'applichero'...ma ormai sono anni che non (ri)compilo un
kernel...
...inutire dire che NON l'ho mai patchato... :-D...
Cmq. ti ringrazio...


 Spero di non scatenare l'ennesimo flame...
Quale flame?  Questo non e' mica it.comp.os.dibattiti ;)
-- 
Lorenzo

 Cos'e` N?
Numero dei processi in coda.
-- 
Lorenzo

Cos'e` N?
Un modo per indicare un numero intero, tipicamente quando questo
rappresenta la cardinalità di un insieme.


 Modifica il valore di HZ in /usr/src/linux/asm/param.h, incrementandolo.
Non sono certo un esperto di kernel programming, ma questo non va a alterare
alcuni timing interni di alcuni moduli?
 
Bye.

alcuni timing interni di alcuni moduli?
Bho. Una volta era una soluzione lecita, e cmq nell'architettura alpha
HZ vale 1024, quindi un modo di modificarlo esiste.


 HZ vale 1024, quindi un modo di modificarlo esiste.
Ne discutevano sulla lk-ml un paio di settimane fa... Non ho seguito il
thread perche' non interessava particolarmente, ma penso basti fare una
ricerchina su Google...
Bye,
 Emmanuele.
-- 
Emmanuele Bassi (Zefram)           [ 
http://www.radiance.d2g.com/~zefram
 ]
GnuPG Key fingerprint = 4DD0 C90D 4070 F071 5738  08BD 8ECC DB8F A432 0FF4

 sola coda).
Hai ragione. Permettimi di disturbarti ancora e di fare il programmatore di
kernel dei poveri. :)
E se si spostasse la complessita` alla fase di modifica delle priorita`?
Cioe`, quando un processo cambia priorita` si riorganizza la coda con
complessita` O(n) o al limite qualcosa di piu` in base all'algoritmo, e in fase
di scheduling si potrebbe comunque mantenere una complessita` O(1), con un
numero fisso di code. Al massimo la complessita` sarebbe O(m) con m=numero
code.
Questo perche` presumo che lo scheduling venga fatto molto piu` spesso che non
la riorganizzazione della coda di priorita`.
Ammetto di non leggere la lkml, quello che so lo leggo su 
lwn.net
 nella
sezione kernel, quindi non so di preciso come funzioni il sistema, ma mi pare
parlassero di uno scheduler O(1) qualche settimana fa.
Bye.

> sono troppo niubbo per cimentarmi in queste cose :-)
Maurizio> Un po` di gente l'ha provata. Funziona. Il che non mi pare
Maurizio> poco.  Ma il concetto "a occhio nudo", insomma...
Ma c'era scritto su linux & c.!
Mi si accappona la pelle della mano sinistra al pensiero della
reattività dei programmi.
Maurizio> Il punto e` che e` molto piu` "percettibile" utilizzare
Maurizio> galeon al posto di mozilla (per dire...).
Oh, quindi, in pratica, dentro galeon c'è una modifica allo scheduler
che lo rende più reattivo.
Ciao
Marco perceptron

>  Cos'e` N?
Zefram> Un modo per indicare un numero intero, tipicamente quando
Zefram> questo rappresenta la cardinalità di un insieme.
LOL
Marco

 Numero dei processi in coda.
Cioe` la complessita` dello scheduler e`
lineare con il numero dei processi in coda?
Deve passarsi tutta la coda, per decidere
chi deve partire?
bye,
-- 
  Piergiorgio Sartor

 discriminare tra N elementi in tempo costante.
La domanda e` se e` *necessario* discriminare
fra N elementi.
Puo` essere possibile pescare direttamente
l'elemento giusto, no?
bye,
-- 
  Piergiorgio Sartor

 rappresenta la cardinalità di un insieme.
Allora avrei scritto O(n) e non O(N),
dato che N rappresenta *tutti* i
numeri naturali :-)
bye,
-- 
piergiorgio

 dell'approccio con una sola coda).
Se mi ricordo bene, funziona cosi`:
Vi sono "n" code, che rappresentano le
varie priorita`, da 1 ad n, dove la 1 e`
quella di priorita` piu` alta (per esempio).
Lo scheduler esegue, in round-robin, tutti
i processi in coda 1, finche` questa e` piena.
Quando non ha piu` processi, questa diventa
la coda "n", la 2 diventa 1 e cosi` via.
I processi "uscenti" vengono messi nella coda
1+k con k>=0 (oppure la coda k, con k>0 :-)).
Ovviamente k non deve essere sempre 0, ma questo
dipende dalla politica di priorita`.
Ed altrettanto ovviamente la priorita` cambia
quando il processo "esce" dallo stato "run" e
viene rimesso in qualche coda.
Questo scheduler dovrebbe essere O(1), dato che
l'accesso alle singole code, ed alla coda di code,
e` sempre un'operazione a tempo costante.
I processi che escono dall'attesa di I/O vengono
posti in testa alla coda 1, a quel punto si
deve decidere se far ripartire lo scheduler od
aspettare il time slice successivo.
Credo questo sia anche lo scheduler di QNX.
bye,
-- 
piergiorgio

 chi deve partire?
Quello dei 2.4 credo di si, ma non e' cosi' grave.
Dovresti avere constantemente un continaio o piu' di processi in stato 
TASK_RUNNING prima che lo scheduler diventi un collo di bottiglia.
http://www.uwsg.iu.edu/hypermail/linux/kernel/0201.0/0810.html
<quote>
and the goal is also to add a few new things: 
 - fully O(1) scheduling. Are you tired of the recalculation loop 
   blowing the L1 cache away every now and then? Do you think the goodness 
   loop is taking a bit too long to finish if there are lots of runnable 
   processes? This new scheduler takes no prisoners: wakeup(), schedule(), 
   the timer interrupt are all O(1) algorithms. There is no recalculation 
   loop. There is no goodness loop either. 
[...]
- O(1) RT scheduling. For those RT folks who are paranoid about the 
   O(nr_running) property of the goodness loop and the recalculation loop.
</quote>
Comunque la complessita' O(1) di certe operazioni dello scheduler e' solo 
una delle tante features di questo nuovo scheduler che e' pensato 
espressamente per macchine SMP ma senza avere overhead eccessivi per
macchine "normali".
-- 
Lorenzo

numeri naturali :-)
No, il simbolo da usare è molto simile ad N ma non uguale :-))


fra N elementi.
Probabilmente sì, se hai più code potresti dover vedere se ci sono
elementi nella coda con i processi a massima priorità, poi la coda con i
processi ad altra priorità, poi... fino alla coda con i processi sfigati
:)
MA, è questo il punto che mi è venuto in mente dopo aver scritto, il
numero di code è molto probabilmente limitato e non dipendente dal
numero di processi che ci stanno dentro, quindi il tempo di
discriminazione, lineare nel numero di code, rimane in realtà O(1).


code.
Sě č cosě (almeno č ragionevole che sia cosě, poi per sapere come stanno
le cose c'č il codice :), supposto uno abbia tempo per poterlo leggere
^__^).


 No, il simbolo da usare è molto simile ad N ma non uguale :-))
Riesci a farlo con ASCII, a 7 bit?
:-)
bye,
-- 
piergiorgio

 discriminazione, lineare nel numero di code, rimane in realtà O(1).
Infatti il numero di code e` persino fisso
a priori ed anche l'ordine.
In realta` il trucco sta nel fatto che cosi`
si puo` ottenere una doppia mappatura,
mantenendo la complessita` O(1).
bye,
-- 
  Piergiorgio Sartor

 Quello dei 2.4 credo di si, ma non e' cosi' grave.
Credi bene. Nella funzione schedule() puoi vedere che la pesatura del
processo (goodness()) viene fatta per ogni elemento della run queue.
-- 
  Giuseppe "Cowo" Corbelli \/\ My software: 
http://cowo.yoda2000.net
    **ANTI-SPAM** -- **Substitute IHATESPAM with cowo to reply by mail**
  -<! A mathematician is a device for turning coffee into theorems. !>-
                P. Erdos

> c'è uno scheduler nel kernel?
No, c'e' una comunita' di folletti che fanno volontariato.....
:)

Non puoi nemmeno paragonare win9x a un sistema operativo serio e basta :D
Non puoi nemmeno paragonare win9x a una sistema operativo e basta :D
-- 
Superciuk

Antonino Sabetta wrote:

wow! ma sono come quelli di babbo natale oppure come quelli che aspirano la 
polvere negli angoli?
scherzi a parte, mi leggo un buon manuale sul kernel hacking e poi mi dò al 
volontariato.
ciao!

 Riesci a farlo con ASCII, a 7 bit?
  ___        ___
   | \        |
   |\ \       |
   | \ \      |
   |  \ \     |
   |   \ \    |
   |    \ \   |
   |     \ \  |
   |      \ \ |
   |       \ \|
  _|_       \_|_
-- 
Saluti,
    Mardy
http://castellina.org/interlingua

 
Questi sono piu` di 7 bit, saranno almeno un migliaio...
:-)
bye,
-- 
piergiorgio

 
ROTFL!!! Un po' grande, ma rende l'idea... ;-)
-- 
 Ciao, Bianco.
 Reply to luca.bianco (at) 
tiscali.it