Newsgroup: it.comp.os.dibattiti
Titolo: 200 righe di patch fanno il miracolo nel kernel Linux

 patch shrinks, which is a good thing. I just wanted to cover all bases.
Yeah. And I have to say that I'm (very happily) surprised by just how
small that patch really ends up being, and how it's not intrusive or
ugly either.
I'm also very happy with just what it does to interactive performance.
Admittedly, my "testcase" is really trivial (reading email in a
web-browser, scrolling around a bit, while doing a "make -j64" on the
kernel at the same time), but it's a test-case that is very relevant
for me. And it is a _huge_ improvement.
It's an improvement for things like smooth scrolling around, but what
I found more interesting was how it seems to really make web pages
load a lot faster. Maybe it shouldn't have been surprising, but I
always associated that with network performance. But there's clearly
enough of a CPU load when loading a new web page that if you have a
load average of 50+ at the same time, you _will_ be starved for CPU in
the loading process, and probably won't get all the http requests out
quickly enough.
So I think this is firmly one of those "real improvement" patches.
Good job. Group scheduling goes from "useful for some specific server
loads" to "that's a killer feature".
           Linus
***********************************
Sottolineo la parte dove Linus dice proprio "it seems to really make web
pages load a lot faster". E gli altri main kernel developer non sembrano
elargire commenti molto dissimili, sono tutti molto eccitati anche
perche' sembra che l'approccio usato sia ulteriormente migliorabile.
L'innovazione, per quello che ho letto finora, sembra che sia nel creare
una nuova forte parallelizzazione dei task (con delle gerachie a
gruppi), proprio a livello di scheduler. L'idea sembra sia stata
suggerita dallo stesso Linus, ma l'implementazione *magica* e' opera di
Mike Galbraith che qui spiega come funziona il tutto e mostra le famose
200 e rotte righe di patch:
http://marc.info/?l=linux-kernel&m=128982080203228&w=2
-- 
BArrYZ

 
Dopo aver visto il video sento di poter dare un commento altamente
tecnico: minchia! :-D
Appena posso patcho e provo.
-- 
Stare dietro a tutti i messaggi di un sistema molto prolisso come linux
è un ottimo modo per farsi male.
 
		-- Giuseppe Della Bianca su I.C.O.L.I.

 
Ho provato subito, causa insonnia :-D
Compilando un kernel con 'make -j 16' e lavorando nel frattempo
(switchando finestre, navigando, etc) la differenza tra
root@attila2# echo 0 > /proc/sys/kernel/sched_autogroup_enabled
root@attila2# echo 1 > /proc/sys/kernel/sched_autogroup_enabled 
La differenza è abissale.
Complimenti ai developers.
-- 
"I ROM non sanno parlare l'italiano, non si integrano, sono aggressivi."
"E come si distinguono dai leghisti?"

 La differenza è abissale.
[autoironia]
Sembra quasi di stare su Windows
[/autoironia]
-- 
"Cuando era presidente del Banco Central de Cuba firmé los billetes con
la palabra Che, para burlarme, porque el dinero, fetiche de mierda, debe
ser feo."
		-- Ernesto Guevara de la Serna


per chi ha voglia (e/o competenza) insufficiente per patcharsi il 
kernel, bisogna aspettare il 2.6.36 (o 37, insomma, il prossimo step) o 
le distribuzioni lo implementeranno entro breve?

 compilazione altamente parallela) si nota qualcosa? 
Io "a pelle" ti direi di sì, ma non so come effettuare una
misurazione oggettiva.
-- 
"Centomila morti" = "È una tragedia!"
"Trovato un superstite" = "Grazie a Dio! È un miracolo!"
WTF!?

 Complimenti ai developers.
ma con renice non risolve?

 ma con renice non risolve?
Non ci ho provato, Suppongo di sì. In ogni caso il renice è qualcosa
che fai "ad hoc" ogni volta che lanci un processo pesante in termini di
elaborazione.  


 
ma è così che dovrebbe essere, lo scheduler di default è fair..

 addirittura *miracolose*:
Ok. Furbo. Vediamo se ho capito: alcuni processi vengono auto-spostati
in un gruppo con una diversa priorita'. E' essenzialmente questo?
-- 
-riko
http://www.enrico-franchi.org/
http://rik0-techtemple.blogspot.com/

 addirittura *miracolose*:
Addirittura? :D comunque gran figata :)
domanda, ci sono miglioramenti nel comparto audio (intesa come latenza nel
recording multitraccia)?
ciao!

 [/autoironia]
Magari hanno copiato quella parte del kernel di Windows 5.1 o 6.1 

 Addirittura? :D comunque gran figata :)
Leggo su reddit e riporto ciecamente:
http://www.webupd8.org/2010/11/alternative-to-200-lines-kernel-patch.html
«Alternative To The "200 Lines Kernel Patch That Does Wonders" Which You
Can Use Right Away»
Basically, you have to add this to your ~/.bashrc file:[...]

 Basically, you have to add this to your ~/.bashrc file:[...]
Visto, ma spero sia inutile dire che la versione a livello di kernel
sia molto meglio...
Raffaele
--
http://rcastagno.blogspot.com

 La differenza è abissale.
Eh, però non entusiasmiamoci troppo. :(
Parole dell'autore:
http://lkml.org/lkml/2010/11/16/423
| The kernel patch discussed here *has* *no* *relevance* for normal users.
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
_____________________________________________________________________
Non sprecare i cicli idle della tua CPU. Usali per qualcosa di utile.
http://orbit.psi.edu/
 
http://www.worldcommunitygrid.org/index.jsp
 
http://boinc.berkeley.edu/projects.php

 molto meglio...
Siccome però la patch scrausa pare ottenere risultati molto migliori[*], 
spero che riscrivano come Dio comanda quella del kernel (che pare pure 
generare qualche errore): di sicuro possono.
[*] 
http://lkml.org/lkml/2010/11/16/392


Ma tutto cio' vale anche su ubuntu? E l'utente ignorantissimo che lo
installa da wizard e openoffice e firefox e niente di piu', cosa deve
fare per ottenere questo "slancio prestazionale"?



deve seguire le istruzioni che ho linkato;
comunque a quanto pare, se non compili tutti i giorni il tuo kernel sembra
che questa patch fenomenale non sia molto utile... (stando a quanto leggo
anche qui)

>>
Raffaele
--
http://rcastagno.blogspot.com/

 I just want to build something, not have terminal emulator in emacs.
It does the same exact thing.  Please actually check and verify
your facts instead of tossing back kneejerk responses.
davem@sunset:~/src/GIT$ cat Makefile
all:
	tty
davem@sunset:~/src/GIT$
"M-x compile" in that directory gives:
--------------------
-*- mode: compilation; default-directory: "~/src/GIT/" -*-
Compilation started at Tue Nov 16 13:13:01
make -k
tty
/dev/pts/2
Compilation finished at Tue Nov 16 13:13:01
--------------------
Raffaele
--
http://rcastagno.blogspot.com/


Attendere che la patch venga inclusa ufficialmente nel tree del
kernel, e che Canonical includa il kernel patchato in Ubuntu stable.
L'auto-update della distro dovrebbe fare il resto.
Raffaele
--
http://rcastagno.blogspot.com/

 users.
Quindi, da quanto  mi sembra di capire, per processi che partono
direttamente da X non dovrebbero esserci cambiamente, giusto?


 direttamente da X non dovrebbero esserci cambiamente, giusto?
Non con *quella* specifica patch, in quanto in quella specifica
implementazione raggruppa per TTY.
Questo non significa che non si possa partire da quell'approccio per
implementare logiche di raggruppamento più avanzate che tengano conto
anche di processi lanciati in altro modo, anche nell'ambito del
desktop ci sono alcuni processi che in realtà non hanno alcun bisogno
di finire in un particolare gruppo, per esempio quelli che per la
maggior parte del tempo sono in idle.
Comunque, l'importante è che sia stato dimostrato che la cosa è
possibile, e che l'approccio di centralizzare tutto nel kernel (che
trovo più sensata) funziona.
Raffaele
--
http://rcastagno.blogspot.com

 Chi ha scritto quello *NON* è l'autore della patch.
Ragione, ho fatto confusione sull'identità. Mi scuso.
Io non ci capisco niente, eh, né ho dedicato alla cosa più d'un minuto,
però continuo a non vedere come una patch o un trick alternativo
potrebbero avere grandi effetti su un desktop se operano per tty/pts.
A titolo d'esempio, attualmente io vedo questo sul pc che sto usando:
lem@biggy:~$ ps au
USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root      1618  0.0  0.0   6080   644 tty4     Ss+  10:12   0:00 /sbin/getty -8
root      1622  0.0  0.0   6080   644 tty5     Ss+  10:12   0:00 /sbin/getty -8
root      1628  0.0  0.0   6080   648 tty2     Ss+  10:12   0:00 /sbin/getty -8
root      1629  0.0  0.0   6080   648 tty3     Ss+  10:12   0:00 /sbin/getty -8
root      1631  0.0  0.0   6080   644 tty6     Ss+  10:12   0:00 /sbin/getty -8
root      1762  1.7  0.4 118448 26072 tty7     Ss+  10:12   5:57 /usr/bin/X :0 -
root      2621  0.0  0.0   6080   644 tty1     Ss+  10:13   0:00 /sbin/getty -8
lem      28843  0.1  0.0  21852  4640 pts/0    Ss   16:02   0:00 bash
lem      29241  0.0  0.0  15256  1204 pts/0    R+   16:03   0:00 ps au
Poca roba (e poco pesante), specie considerando che:
lem@biggy:~$ top
top - 16:20:08 up  6:08,  2 users,  load average: 3.96, 2.79, 2.52
Tasks: 226 total,   3 running, 223 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.2%us,  1.8%sy, 94.9%ni,  0.0%id,  0.0%wa,  0.0%hi,  0.2%si,  0.0%st
Mem:   5994468k total,  5848008k used,   146460k free,    93456k buffers
Swap: 12287992k total,        0k used, 12287992k free,  4594860k cached


>>
Inoltre, nulla vieta che alla fine vengano implementate in qualche
modo entrambe le soluzioni, eh.
Raffaele
--
http://rcastagno.blogspot.com

 Ok, ma leggiti anche la risposta di Linus:
Forse non mi sono capito. ;)
Guarda che io dicevo proprio questo: devono scrivere meglio la patch del 
kernel, perché è a quel livello che è opportuno operare. E non c'è 
ragione - questo dicevo - che 'sta cosa fatta nel kernel debba andare 
peggio del trick fatto fuori del kernel. Vorrà dire che per ora non è 
stata fatta bene come invece potrebbe, credo.


 task.
Dammi conferma se ho capito, che ora non mi va di leggere astruse
discussioni altrove.
I cgroups ci sono dalla 2.6.24, cioè da un sacco di tempo. L'attuale 
novità è solo che si cerca di portarne lo sfruttamento automatico
nel kernel, mentre "trick" vari sono sempre stati possibili[*]. Il
problema grosso è che, mentre i trick sono flessibili e, sapendolo
fare, li posso costruire in base alle mie necessità, se voglio
portare 'sta roba nel kernel devo decidere prima almeno un set rigido
di criteri di raggruppamento da cui poter estrarre "matrici di
raggruppamento"... magari anche senza esagerare, neh! ;)
O si fanno cose semplicissime, ma scarsamente utili in molte
situazioni, com'è il caso di questo primo tentativo, o per i
programmatori sono volatili per diabetici... per ora.
Più o meno ci sono?
[*] In tempi non sospetti:
http://stacktrace.it/2009/05/linux-kernel-hacking-contenitori-di-processi/
http://stacktrace.it/2009/05/linux-kernel-hacking-contenitori-di-processi2/


 Più o meno ci sono?
Più o meno. Nel kernel devi stabilire criteri fissi o dinamici
estrapolandoli dal sistema, mentre col sistema manuale puoi variare
tali criteri ad-hoc.
MA nel kernel lo puoi fare in maniera più semplice dal punto di vista
del programmatore perchè sei in kernel-space, quindi tante pippe te le
puoi evitare, inoltre lo puoi fare in automatico, perchè non è
richiesta alcun intervento da parte dell'utente.
Inoltre, facendo una simile ottimizzazione centralizzata nel kernel fa
si che i benefici siano disponibili a tutti coloro che usino il
kernel, sia che lo usino con KDE e tutta la sua fuffa, con una shell
minimale, o senza shell alcuna, perchè è il kernel stesso ad occuparsi
di quelle ottimizzazioni.
Ovvero, tra una soluzione che *può* eventualmente essere migliore
*ora*, ma che richiede una configurazione in bashrc a livello utente,
Linus imho giustamente predilige una soluzione che forse *ora* non è
ottimale, ma che a tendere può portare benefici a *tutti* su ogni
piattaforma, a prescindere da come sia configurato il resto del
sistema.
Come ha detto Linus, qualcosa del tipo "asking a user to configure is
not a feature".
Raffaele
--
http://rcastagno.blogspot.com

 stata fatta bene come invece potrebbe, credo.
Ah, ok. Si, si può fare meglio, resta comunque un enorme risultato per
una patch da 200 righe.
Raffaele

 semplicemente dello spocchioso di turno.
Ti prego di dare a Cesare quel che è di Cesare; Lennart NON è lo spocchioso
di turno: è lo spocchioso di PulseAudio :D :D (un gran cagacazzo)

 di turno: lo spocchioso di PulseAudio :D :D (un gran cagacazzo)
Il mondo è purtroppo pieno di persone competenti, ma altresì
spocchiose.
Raffaele
--
http://rcastagno.blogspot.com

 not a feature".
Cazzo, stanno cominciando a capire come vanno fatte le cose.


 maggior parte del tempo sono in idle.
Ok, adesso ho capito. Grazie mille per il chiarimento.


 Cazzo, stanno cominciando a capire come vanno fatte le cose.
quoto!
Ciao Jack

 caratterino.
OT: a questo proposito, questo
http://www.reddit.com/r/linux/comments/aqq6w/pulseaudios_error_messages/
� uno dei miei preferiti.
| E: module-udev-detect.c: You apparently ran out of inotify watches,
| probably because Tracker/Beagle took them all away. I wished people
| would do their homework first and fix inotify before using it for
| watching whole directory trees which is something the current inotify is
| certainly not useful for. Please make sure to drop the Tracker/Beagle
| guys a line complaining about their broken use of inotify.
soprattutto se questo commento � vero
http://www.reddit.com/r/linux/comments/aqq6w/pulseaudios_error_messages/c0ixqqn
| That's kind of a funny error message because the guy who wrote inotify 
| was also one of the original authors of Beagle.

anche qui)
Cioe' quella modifica velocizza solo la ricompilazione del kernel??
Allora non ho capito niente, pensavo velocizzasse in generale tutto il
sistema.

 sistema.
Da quanto ho capito prendendo pezzi di qua e di là, la patch rende più
reattivo il sistema nel momentoin cui una (o più) applicazioni lanciate
da shell occuoano in modo pesante il processore. La compilazione del
kernel con -j n (con n alto) è una di queste. Ma potrebbe, immagino,
anche trattarsi di calcolo numerico pesante e questioni affini.
-- 
Dirac was known among his colleagues for his precise and taciturn
nature. His colleagues in Cambridge jokingly defined a unit of a dirac
which was one word per hour.

 spocchiose.
E a qualcuna di queste persone dedicano anche un NG :-) 

 [/Autoironia]
Quale Windows? Non mi pare che lo scheduler di XP sia così memorabile.
-- 
                     Dona i tuoi cicli di clock alla ricerca!
 
http://boinc.berkeley.edu/
                          --------------------
            SCIMUNITO - Attrezzato per gli sport invernali.

 tali criteri ad-hoc.
Un'idea che mi è venuta così e magari è una cazzata... ma nessuno ha mai
pensato di implementare una rete neurale per calcolare i parametri di
ottimizzazione? Inoltre una soluzione del genere avrebbe il vantaggio di
adattarti automaticamente ad ogni computer nella sua unicità.
-- 
                     Dona i tuoi cicli di clock alla ricerca!
 
http://boinc.berkeley.edu/
                          --------------------
         Seconda Legge di Hartley:
         	Non andate mai a letto con gente piu' strana di voi.

 Cazzo, stanno cominciando a capire come vanno fatte le cose.
Concordo, e mi compiaccio che quest'affermazione venga fatta da un nerd
come lui. Purché non chiudano il cofano a chiave possono fare quello che
vogliono.
-- 
                     Dona i tuoi cicli di clock alla ricerca!
 
http://boinc.berkeley.edu/
                          --------------------
   Potrei essere Capitano per anzianita', ma non ho mai voluto essere
   nient'altro che un ingegnere.
   		-- Scott, "Relics" (TNG), data astrale 46125.3

 ottimizzazione?
Scetticismo, qui. Prova a descrivere come struttureresti il processo.
Magari sbaglio io, eh.


 Magari sbaglio io, eh.
Scrivi un motore euristico collegato al microfono: aumenti la priorità
dei processi nel momento in cui l'utente inizia a smadonnare.
Che so: "ca**o, questa compilazione non và avanti" e *ZAC*! Il kernel
aumenta la priorità e la compilazione và più veloce! :)
Raffaele
--
http://rcastagno.blogspot.com

 dei processi nel momento in cui l'utente inizia a smadonnare.
Ah, LOL. Ma poi metti il culo nelle mani di Lennart. :)


 aumenta la priorità e la compilazione và più veloce! :)
LOL.
si potrebbero anche usare gli accelerometri che ci sono sugli HD,
quando cominciano a rilevare vibrazioni forti o e' un terremoto oppure
e' il tizio che sta tirando pugni sul tavolo per la frustrazione.
Si puo' ovviamente combinare col microfono per capire se
effettivamente e' un terremoto oppure no.
:)
Ciao Jack

 Quale Windows? Non mi pare che lo scheduler di XP sia così memorabile.
Mi riferivo al fatto che, in tutta onestá, la reattività della GUI di
Windows mi è sempre sembrata superiore.
-- 
Un popolo che gioisce/s'intristisce per il calcio merita l'estinzione.

 Windows mi � sempre sembrata superiore.
ma sempre in tutta onest� per qualche ragione quando Windows swappa � molto
meno reattivo in confronto (almeno parlo di XP versus una vecchia Ubuntu,
adesso non so com'� la situazione)

 vecchia Ubuntu, adesso non so com'è la situazione)
Sì, questo è verissimo.
-- 
Physicists are notoriously scornful of scientists from other fields.
When the great Austrian physicist Wolfgang Pauli's wife left him for a
chemist, 'Had she taken a bullfighter I would have understood. But a
chemist ... ?' he remarked in wonder to a friend.