domenica 21 febbraio 2010

Completely Fair Schedulers, Bankers and Anaesthesists

Uno degli ingredienti chiave della ricetta Linux RT_PREEMPT e' la modifica allo scheduler ovvero l'adozione di CSF (Completely Fair Scheduler) sviluppato e mantenuto da Ingo Molnar (si, sempre lui).

A causa un errore di battitura nella finestra di ricerca di Google, sono andato a finire su questo link:

http://it.wikipedia.org/wiki/Federico_Guglielmo_Raiffeisen

Insomma, ho trovato un banchiere onesto. Leggere che la chiesa cattolica ed un banchiere ebreo si sono messi a lavorare insieme per migliorare le condizioni economiche delle campagne italiane, fa semplicemente impressione.
Certo, erano altri tempi. Penso che sia inutile che vi citi recenti esempi di malefatte di banchieri ebrei e istituti cattolici: questo blog non vuole focalizzarsi troppo sul Lato Oscuro. Ce n'e' piu' che abbastanza, inutile fare ulteriore pubblicita' gratuita. Come dice sempre Camilleri, cerco sempre di parlare il meno possibile della Mafia.

Lavorare nel mondo Open Source e' interessante perche' s'incontra della gente strana. Se frequentate i soliti ambienti professionali, dopo quanche anno vi renderete conto i personaggi sono preconfezionati al livello di "Camera Caffe". Vi restano quindi due alternative:
(pillola blu): continuate ad andare prendete il caffe' con i vostri soliti colleghi di lavoro;
(pillola rossa): saltate il fosso: andate a vedere quanto e' profondo il pozzo di Alice.

Lo scheduler CFS, anche se e' scritto e mantenuto da Ingo, deve molto ad un lavoro pluriennale di un medico anestesista australiano. Chi meglio di un anestesista poteva decidere come e quando mettere a dormire e risvegliare i processi di Linux?

Perche' un medico anestesista si dovrebbe mettere a sviluppare una delle parte piu' critiche (forse la piu' critica di tutte) di un sistema operativo complesso come Linux ?

La risposta e' semplice: Con Kolivas si era stufato di vedere il desktop di Linux rimanere congelato per decine di secondi.

Per capire meglio il problema, saltiamo sulla nostra mitica DeLorean e ritorniamo nel lontano Novembre 1999, quando il mondo era sulle spine per il Millenium Bug.




Windows '98 era uscito da alcuni mesi. Mentre tornavo a casa dal lavoro, nei 45 minuti di auto, mi dovevo sorbire almeno tre spot sull'ultima trovata proveniente da Redmond. Lavoravo in una ditta che aveva deciso di usare Windows 95 a tappeto per gli applicativi e le interfacce uomo/macchina delle macchine "robotiche" che produceva. La cosa mi toccava fino ad un certo punto, visto che tutte le funzioni critiche erano gestite da una scheda DSP dedicata: hardware e software proveniente dalle manine d'oro del sottoscritto e dei suoi colleghi. Facciamola corta: non siamo mai riusciti a misurare l'affidabilita' della nostra creazione perche' il PC ospite (con Win 95) aveva un uptime medio di otto ore.
Nel manuale d'istruzioni c'era scritto chiaro e tondo che la macchina doveva passare attraverso un ciclo completo di reboot all'inizio di ogni turno di lavoro (di otto ore appunto).

Siccome i miei colleghi che avevano provato il '98 mi avevavo raccontato storie allucinanti, colsi al volo l'occasione per guardare altrove.

Verso la fine del 1999, mi comprai una scatola di cartone con Corel Linux 1.0 dentro. Corel aveva creato una distribuzione completa con KDE 1.0: il primo vero desktop di Linux che non spaventava troppo gli utenti provenienti da Windows.
Usarlo era un vero piacere, salvo che, ogni tanto, il desktop restava congelato. La cosa piu' strana era che il mouse non si muoveva piu'. Su Windows, se il puntatore del mouse rimane congelato non c'e' piu' nulla da fare. Su Corel Linux accadeva piuttosto spesso, poi tutto continuava a funzionare come al solito.

I giochi (spettacolare il primo porting di Quake III Arena per Linux su Voodoo 3000 AGP) andavano bene, salvo dei fastidiosi momenti di "freeze". Erano ancora i tempi del kernel 2.4.x.

Nel bene e nel male Linux e' stato sempre piu' ottimizzato per applicazioni server piuttosto che per applicazioni desktop. Solo recentemente si e' posta la necessaria attenzione all'utente singolo.

Con Kolivas comincio' quindi a pensare di modificare lo scheduler per evitare questi fatidiosi tempi morti senza per questo bruciare il 25% del processore solo per spostare il bitmap del mouse come succedeva con Win 95.

Siccome il software non e' mai stato il mio forte, all'epoca decisi di risolvere il problema con un altro approccio: farmi la mia prima macchina biprocessore. La Intel aveva lasciato il supporto SMP attivo sui processori economici di classe Celeron (che costavano la meta' dei Pentium III dell'epoca, Dicembre 1999).

La Abit produsse una motherboard con due zoccoli (BP6) Celeron compatibili. Decisi quindi di fare la spesa: mother board e due processori nuovi di zecca.

Una volta arrivato a casa, verificato che il PC funzionava, feci il boot con il disco di Linux. Close but not cigar. Il kernel fornito di serie NON supportava il multi processore.

Una delle cose simpatiche della scatola di cartone di Corel era il manuale allegato. In uno degli ultimi capitoli c'era spiegata la procedura passo passo per ricompilare il kernel, con una sezione dedicata alle macchine SMP.
Dopo i canonici 15 minuti necessari alla ricompilazione, reboot e ... voila! Due processori ! Quake volava, fluido come non mai.
Anche la risposta agli interrupt era migliorata in modo significativo, anche se non era ancora hard real time.

Purtroppo la mia fidata BP6 mori' nel 2000 a causa di un colpo diretto da fulmine, un fulmine a cel sereno che mise fuori uso anche televisore e lavatrice. Da quel giorno ho installato filtro, trasformatore d'isolamento e UPS.

Qualche anno fa mi sono comprato, per una manciata di euro, una scheda doppio processore con due Pentium II SLOT-1. Bella, ma non e' la stessa cosa. La VP6, successore della mitica BP6, non arrivo' mai ad Arezzo. 

(...continua...)

Nessun commento:

Posta un commento