Newsgroup: it.comp.os.dibattiti
Titolo: Fairsched

Avete mai provato a far girare (in qialsiasi OS) 256, ma il numero
potrebbe essere anche piu` alto, processi tutti in stato di *running*?
Provateci. Se non avete una shell o una GUI settata a real time
praticamente il sistema e` inutilizzabile.
Qualche tempo fa venni a conoscenza di una patch per Linux denominata
fairsched, dopo averla provata non credevo ai miei occhi.
Cosa fa? E` semplicissima, se un utente monopolizza la CPU con un
fork-bomb per esempio (i 256 processi di prima) ogni altro processo
che fara` partire sara` fortemente svantaggiato in termini di time slice
rispetto ad un processo di un utente che abbia solo pochi processi in
stato di running. In breve, chiunque voglia rubare tempo di CPU a
scapito degli altri non ci riuscita` perche` la politica ora adottata
dallo scheduler e` una politica fair, appunto. Questo a spizzichi e
bocconi, qui c'e` un piccolo commento e per chi se la sente puo` anche
studiarsi il codice ;-)
/*
 * Simple, low-overhead fair share scheduler. It works by handing
 * out CPU time like we do at the normal recalculation.
 * The catch is that we move the list head (where the for_each_task()
 * loop starts) to _after_ the first task where we ran out of quota.
 * This means that if a user has too many runnable processes, his
 * tasks will get extra CPU time here in turns. -- Rik
 */
Ecco uno screenshot di top:
 11:24am  up 54 min,  5 users,  load average: 255.60, 255.34, 234.34
 286 processes: 29 sleeping, 257 running, 0 zombie, 0 stopped
 CPU states: 553.0% user, 11.9% system,  7.2% nice,  0.0% idle
 Mem:   15036K av,  14536K used,    500K free,   5976K shrd,    400K buff
 Swap:  40316K av,   9200K used,  31116K free                  3040K cached
 
  PID USER     PRI  NI  SIZE  TRS  RSS SHARE STAT %CPU %MEM   TIME COMMAND
  242 fermat    20   0    72    4    4     4 R    99.9  0.0   0:11 fork
  347 fermat    20   0    72    4    4     4 R    99.9  0.0   0:08 fork
  406 fermat    20   0    72    4    4     4 R    93.6  0.0   0:06 fork
  449 fermat    20   0    72    4    4     4 R    72.9  0.0   0:05 fork
  249 root       6   0   604   32  528   324 R    17.7  3.5   7:15 top
  207 allegro   20  19   220  168  196   152 R N   7.2  1.3   9:53 rc5des
  319 fermat    20   0    72    4    4     4 R     2.9  0.0   0:09 fork
  308 fermat    20   0    72    4    4     4 R     2.9  0.0   0:09 fork
  309 fermat    20   0    72    4    4     4 R     2.9  0.0   0:09 fork
  310 fermat    20   0    72    4    4     4 R     2.9  0.0   0:09 fork
  312 fermat    20   0    72    4    4     4 R     2.9  0.0   0:09 fork
  301 fermat    20   0    72    4    4     4 R     2.9  0.0   0:10 fork
  302 fermat    20   0    72    4    4     4 R     2.9  0.0   0:10 fork
  303 fermat    20   0    72    4    4     4 R     2.9  0.0   0:10 fork
  304 fermat    20   0    72    4    4     4 R     2.9  0.0   0:10 fork
  305 fermat    20   0    72    4    4     4 R     2.9  0.0   0:10 fork
  306 fermat    20   0    72    4    4     4 R     2.9  0.0   0:10 fork
  307 fermat    20   0    72    4    4     4 R     2.9  0.0   0:10 fork	  
Ho questa situazione mentre vi scrivo e se non sapessi che ci fossero
tutti quei processi con <C mode> while(1) {} </C mode> non avrei nessun
indizio della loro presenza.
Oh beninteso, tutto questo senza settare nessuna priorita`, non c'e`
trucco! In mio slrn ha la stessa priorita` di quei CPU hogs!
Si sarebbe ottenuta la stessa cosa settando la propria shell a RT
ma sarebbe stato banale, e poi solo root puo` farlo.
Se non mi credete provatela, si trova su 
http://www.surriel.com/patches/
La patch e` per il 2.2.14.
Il nucleo della patch consiste in una cinquantina di righe di codice,
ben al disotto di qualche decina di milioni di LOC...
Credo che questa patch sia un must per i sistemi multiutente dove i
singoli utenti non hanno (ovviamente) il diritto di alzarsi la priorita`
dei propri processi ne tanto meno quello di abbassarla agli altri.
Limitare all'osso il numero dei processi che un utente puo` far
girare non e` una soluzione al problema e puo` limitare fortemente
l'attivita` dell'utente.
-- 
Lorenzo
"Given enough eyeballs, all bugs are shallow", Linus'Law
(address rot13 encoded)

Solaris lo fa di default ed infatti, il sistema risponde senza grossi
problemi al fork bombing (ovviamente è più lento)
Ciao
UltraSparc

 stato di running.
L'idea e' buona, ma  vale solo per il numero di  processi o pure per
il "consumo" di CPU  ? Cioe', 20 sessioni di slrn  pesano di piu' di
un solo seti@home ?
-- 
                                                                     __
 __                                                              _  ///
| _        Student in Computer Science, Swiss Federal Institute  \\///
|__|iambo      of Technology - mailto:
ggia...@iiic.ethz.ch
       \X/

problemi al fork bombing (ovviamente è più lento)
A occhio non ho notato rallentamenti apprezzabili.
Se fosse attivato, basta un semplice "echo 1>/proc/sys/kernel/fairsched"
e non lo sapessi, non penso che me ne accorgerei.


un solo seti@home ?
In che senso? seti@home avra` pure un nice 19 che complica le cose.
Se tu hai un utente che fa girare decine di processi tutti nella
maggior parte del tempo in stato di running, con la patch sei ancora
in grado di lavorare come se l'utente "cattivo" non esistesse.
Questo sul piano del response time, sul piano della %CPU anche li`
ottieni degli ottimi risultati, impossibili da ottenere senza patch.


potrebbe essere anche piu` alto, processi tutti in stato di *running*?
eh, credo di essere arrivato attorno ai 600...
Obelix

 problemi al fork bombing (ovviamente è più lento)
Forse sono i nostri sistemisti  imbranati, ma un'Ultra10 andava giu'
dopo pochi secondi di fork bombing  ... Forse si riempiva la tabella
dei processi ?
-- 
Giambo - Che non ha ancora configurato per benino il nuovo PC M$-Free :-9

 dei processi ?
Allora, torniamo un po' indietro...
La faccenda del fork bombing nasce da un mio antichissimo post sul problema
che aveva il mio (mio perché sulla mia macchina) kernel linux nel
confrontarsi con crashme.
Nacque una discussione lunga, e Lorenzo posto' un url (o il codice) del
fork-bomber. Io lo provai al volo e la mia Ultra cadde in men che non si
dica...
A quel punto grazie all' aiuto di Lorenzo capii che lanciare il fork bomber
da root, permetteva di raggiungere l' hard-limit dei processi e la macchina
stallava nonostante il meccanismo di latenza che il kernel innesca quando
dei processi forkano troppo. Lavorando da utente normale con l' ulimit
impostato non ho avuto più problemi. Comunque quale sistema girava sulla
Ultra e quali patch?
Ciao
UltraSparc

 e non lo sapessi, non penso che me ne accorgerei.
Io non ho ben chiare un paio di cose. Dal tuo messaggio originale vedo....
CPU states: 553.0% user, 11.9% system,  7.2% nice,  0.0% idle
Inoltre non vedo (ma prob. non hai postato tutto il top) una sessione X
attiva.
Tieni conto che in genere Solaris lavora sempre in modalità grafica. Credo
che il fork bombing renda comunque difficile una risposta rapida di X. Su
console senza X non ho mai provato. Dammi qualche oretta e provo sulla 8 di
solaris questa volta...
Ciao
UltraSparc


Grazie, ti sto parlando di un P75 16 Mb...


 A occhio non ho notato rallentamenti apprezzabili.
Dimenticavo...
Ho rilanciato su Solaris 2.7/Sparc il forkbomber (con la versione 8 ho
problemi) e il numero di processi avviati arriva a 3844. Forse è anche per
questo che va un po' pianino.
Cosa ne pensi?
Ciao
UltraSparc

solaris questa volta...
Ok.


Cosa ne pensi?
Che 3844 processi sono troppi!
Non devi usare root, usa un utente con limiti ragionevoli.



L' otto è delicatissimo attualmente. Si imballa al volo. Ho già informato
SUN.
Saluti
UltraSparc

 terminali virtuali...
scusa ... console
Ciao
UltraSparc

SUN.
Forse "sembra" inchiodato, basta aspettare :-)


Grazie, ti sto parlando di un P75 16 Mb...
Non hai scritto nulal di cio, nel mex di apertura: hai parlato di
*qualsiasi OS* (io parlavo di un PPC 120mhz con 80mb di ram..)
Obelix

 Forse "sembra" inchiodato, basta aspettare :-)
Dopo 45 minuti devo aspettare ancora :-)) ?
Ciao
UltraSparc

 Non devi usare root, usa un utente con limiti ragionevoli.
Infatti non uso root. Solaris conta da solo l' ulimit per gli utenti.
maxusers = memoria di sistema in megabyte.
max_nprocs = (10 + 16 * maxuser)
maxuprc = (max_nprocs - 5) (maxuprc č il numero di processi avviabili dall'
utente). Con 256 MB di ram abbiamo 4101 (processi al massimo per un utente).
La cosa che mi ha stupito č che ieri mi sono arrivati altri 256 MB. Con 512
MB il numero di processi utente arriva a 8197 e il forkbomber blocca il
sistema completamente. Facendo l' override di maxuprc arrivo a 6500 senza
problemi, salendo ancora la macchina si ferma.
Deve esserci un bug grosso come una casa.
Forse i sistemisti di cui parlava Giambo avevano sulla Ultra un casino di
ram.
Ciao
UltraSparc

 Ne bastano un centinaio, sei sicuro che sono tutti in running?
Allora, bella domanda questa. Non riesco a mandarli tutti in run. Con il top
ne ho visti al massimo 13 running con ulimit impostato a 300.
Perché non sono in running?
Ciao
UltraSparc

 Comunque quale sistema girava sulla Ultra e quali patch?
Mi chiedi troppo. Comunque sono sempre piu' propenso a credere che i
nostri sistemisiti siano imbranati :)



Direi di no.


Perché non sono in running?
Perche` non usi un forkbomb giusto :-)


 casino di ram.
128MB, mi pare. Conta pure la "swap" ? E poi non sono i sistemisiti:
Le Ultra sono per tutti :-)


 Perche` non usi un forkbomb giusto :-)
Mi passi via mail il sorgente corretto?
Ciao
UltraSparc

 Le Ultra sono per tutti :-)
No, lo swap non conta. Conta solo la ram.
Perché i tuoi sistemisti non hanno la ram ;-))?
Ciao
UltraSparc