Newsgroup: it.comp.os.linux.sys
Titolo: Equita' ed efficienza nello scheduler: trade off emergente?

Riflettendo sull'eventuale opportunità di bindare alle singole cpu,
tramite taskset o meglio schedtool, i processi di computazione
diffusa avviati da BOINC, m'è capitato di leggere
http://www.mattheaton.com/?p=222
 - fate finta di credere che io
possa conoscere anche marginalmente l'argomento. ;)
M'è sembrato tutto interessante (naturalmente la curiosità mi ha
spinto ad andar subito a leggere l'output di /proc/sched_debug e di
alcuni /proc/PID/sched): per fortuna almeno qualche valore è intuitivo. 
Solo la chiusa dell'articolo mi ha sorpreso: io credevo che il
group scheduling (insomma quel comportamento in base al quale lo
scheduler non tratta tutti i processi come uguali, ma prima tratta
come uguali i gruppi di processi - per esempio proprio gruppi per
utente) fosse una realtà ben consolidata già dagli albori del CFS,
insomma dal kernel 2.6.24 o giù di lì:
http://kernelnewbies.org/Linux_2_6_24#head-16d608b6aba030fe15ba3bbc75655391ae98d707
Anche a parte questo, ogni chiosa è benvenuta: io non sono proprio in
grado di commentare, ma sarei molto interessato a leggere le vostre
considerazioni in merito.  
-- 
Bye, Lem
Ceterum censeo ISLAM esse delendum
____________________________________________________________________________
Non sprecare i cicli idle della tua CPU: 
http://boinc.berkeley.edu/index.php

 insomma dal kernel 2.6.24 o giù di lì:
Sinceramente non vedo come il group tasking di CFS ci azzecchi con 
l'articolo in questione. Il tizio di BlueHost semplicemente si sta 
lamentando del fatto che il CFS abbia troppo overhead di scheduling per 
processo. Quindi in scenari ad alta concorrenza, il kernel perde 
praticamente tutto il tempo a schedulare (muovere di CPU, attivare/fermare 
processi) e non a eseguire il codice del programma.
-- 
Vide

 Lem Novantotto wrote:
Mi hai risposto solo in privato, mi sa che ti sei sbagliato :)
-- 
Vide

 Mi hai risposto solo in privato, mi sa che ti sei sbagliato
Sì. Grazie del riscontro.
Infatti mi stavo proprio chiedendo dove fosse finito il mio post. :)
Mi ripeto qui: il passo della chiusa in cui vedo il riferimento
al group scheduler è questo:
| How do we fix it? Well, we actually have a “process start throttler” 
| kernel patch [...] it stops a single user that launches a ton of 
| processes at once from impacting the speed and stability of everyone 
| else on the system.
Ma ero curioso anche sulla questione generale dell'inefficienza del CFS
con molti task, a prescindere dal group scheduling.


 con molti task, a prescindere dal group scheduling.
Ti ringrazio infatti per il link, molto interessante. 
-- 
Vide

 l'overhead sia unico, però probabilmente non è così.
Sì, io m'ero fatto l'idea che in uno scheduling "a due stadi"
(cioè prima alloco tempo ai gruppi, e poi ai processi in ogni gruppo)
l'overhead necessario per gestire i processi in ogni gruppo
facesse parte del tempo destinato a quel gruppo. Così, se tu lanci
due processi e io duemila, tu prendi circa il 25% del tempo totale a 
processo, e l'inefficienza dello scheduler - come giusto - me la becco
tutta io.
Mi sembrava sensato così, e l'ho dato per scontato, quando invece
era solo una mia invenzione.
Ma hai sicuramente ragione tu: se hanno questo problema, dev'essere per
forza come dici tu. :)
