Versione in lingua inglese: Interview with Rik van Riel
Rik van Riel è nato in Olanda nel 1978. Ha iniziato ad usare GNU/Linux nel 1994 ed attualmente è uno dei più attivi sviluppatori di Linux. Dopo aver lavorato come consulente Linux per una società olandese, è stato assunto da Conectiva S.A., la più grande azienda Linux del Sud America. Il suo impegno per Linux è rivolto principalmente alla gestione della VM. Assieme ad Andrea Arcangeli è stato il responsabile della gestione della Virtual Memory per i kernel 2.2 e 2.4.
Ciao Rik. Prima di tutto vorrei ringraziarti per la tua cortese disponibilità.
Ciao. Sono a tua completa disposizione.
Con l'uscita del kernel 2.4.10 abbiamo visto che Linus Torvalds ha preferito la VM di Arcangeli alla tua. Cosa pensi di questa decisione? Perché l'ha fatto?
È stata una strana situazione, prima Linus ignora i bugfix fatti da me e da Alan per quasi un anno, poi si lamenta che "non gli abbiamo spedito" i bugfix e ha naturamente sostituito la VM. La nuova VM ha migliori performance rispetto alla vecchia sui tipici sistemi desktop ... ma fa fiasco terribilmente su più sistemi di quanto non lo facesse la vecchia VM. Redhat, per esempio, non ha potuto inserire la nuova VM nella sua distribuzione perché cadrebbe a pezzi per i database server, alcuni dei suoi utenti usano già ora il mio codice... è andata che io non devo più lavorare assieme a Linus, che è una cosa buona ;)
Perché è una buona cosa?
Senza Linus, posso fare una buona VM. Non devo più preoccuparmi di cosa piace o non piace a lui. Questo è molto importante per il codice intermedio, dove alcuni degli "elementi" di una VM sono già dentro mentre altri non lo sono ancora. Questo tipo di codice può sembrare brutto e inutile se non hai il tempo di guardare al progetto per alcuni giorni, così Linus tende a rimuoverlo ... sebbene abbia bisogno solo di continuare con lo sviluppo.
La nuova VM ha causato le critiche di molti degli sviluppatori, che hanno visto in questa modifica così radicale un motivo di instabilità. In particolare anche le tue parole sono state molto aspre: «Guarda, il problema è che Linus è diventato deficiente [is being an asshole: il termine asshole ha connotazione fortemente volgare e offensiva come si può notare e non ha un equivalente in italiano N.d.T.] e sta integrando idee opposte nella VM e nel VFS, senza prima dirlo a nessuno e dando la colpa poi ad altri». Sei sempre dello stesso parere?
Sì, sebbene credo di dover aggiungere che io ho molto rispetto per Linus. Lui ha un sistema di gestione del codice veramente poco amichevole, ma è anche molto onesto su questo. Una soluzione per appianare questa divergenza secondo me potrebbe essere quella di un sistema automatico per le patch, un programma per computer che rimanda automaticamente le patch a Linus. In questo modo posso usare Linus solo come un programma intelligente di gestione del codice e non devo preoccuparmi di dover rispedire una patch cinquanta volte prima che entri nel kernel perché questo sarebbe automatico ;)
Sembra non scorra buon sangue tra te e Torvalds ultimamente. È vero?
Veramente non gli serbo rancore o altro. La verità è che sono ostinato come lui e non posso sopportare il modo in cui il sistema di controllo del codice sorgente di Linus funziona. Sostengo che una volta che un sistema automatizzato per le patch sia in atto (un sistema simile al TCP che faccia capo al sistema di controllo del codice sorgente che Linus perde) saremo entrambi molto più felici.
Spero che voi possiate appianare le vostre divergenze. Anche Alan Cox dopo aver continuato ad usare la tua VM nel suo kernel, a un certo punto ha ritenuto la VM di Arcangeli abbastanza sicura da poter essere usata, come hai visto la cosa?
A giudicare dal fatto che Redhat sta usando la mio vecchio VM con il 2.4.17 per essere usato nei loro kernel in formato RPM, immagino che sia tornato su quella idea.
Sto continuado a seguire il tuo sviluppo dell' OOM Killer e il tuo approccio alla VM con il Reverse Mapping e li sto trovando molto interessanti, ma forse difficili da mettere in pratica in maniera efficiente. Potresti spiegare ai nostri lettori di cosa si tratta?
Comincerò con il killer OOM poichè questo è facile da spiegare.
Alla base di un sistema Linux c'è una certa quantità di RAM e di swap. La RAM è usata per i dati Kernel, per conservare file eseguibili, le librerie e i dati del disco e per conservare la memoria che usano i programmi. Come è risaputo, i sistemi non hanno RAM a sufficienza, così si deve scegliere quali dati tenere nella RAM e quali spostare nello spazio swap. Comunque in alcune situazioni i sistemi non hanno spazio swap a sufficienza e il sistema non ha proprio lo spazio necessario per gestire tutti i programmi che si erano iniziati. In una situazione del genere si può o attendere finchè qualcuno liberi (si libera) la memoria (non è possibile se tutti aspettano) oppure è necessario fare assolutamente spazio, per esempio eliminando un processo. Naturalmente non si vuole che sia eliminato un processo a caso, che potrebbe essere init, syslogd o qualche altro processo critico. Il killer OOM è responsabile nell'individuare quando il sistema è privo di memoria e di swap e nel selezionare il processo giusto (o meno brutto) da eliminare.
Il bisogno del reverse mapping (rmap) è molto più complesso da spiegare, ma alla base il vecchio VM sta facendo fronte a un numero di problemi:
- Abbiamo diverse zone di memoria e abbiamo bisogno di tenere delle pagine libere in ogni zona.
- Le pagine possono essere ripartite per molti processi, ma non sappiamo quali.
- Abbiamo bisogno di equilibrare la liberazione delle pagine della cache e quelle dei processi.
Questi tre problemi in definitiva si riducono ad un solo problema, non sappiamo quanto sia usata una particolare pagina nella RAM o chi la stia usando. Nella vecchia VM, per esempio, poi si può avere la situazione in cui i programmi stanno usando pagine nella zona di 16mb del DMA ISA, ma potresti aver bisogno di fare uno scan della memoria di tutti i processi per liberare una pagina in quella zona siccome non sai chi sta usando quelle pagine.
Il reverse mapping tenta di risolvere questo problema seguendo le tracce di chi sta usando ciascuna pagina. Così, possiamo proprio scansionare le pagine di memoria nel DMA e liberarne una che non è molto usata, intendendo dire che noi abbiamo bisogno di scansionare al massimo i metadati per 16 MB di pagine ... in pratica una di gran lunga minore di quella. Vuol dire anche che noi possiamo fare uno scan dei processi e della memoria cache usando lo stesso algoritmo, semplificando molto quella parte della VM.
Attualmente il rmap è ancora in via di sviluppo, ma in gran parte delle situazioni dove la normale VM funziona bene la prestazione del rmap è simile. Quindi ci sono alcune situazioni in cui la normale VM cade a pezzi a causa dei problemi che ho descritto prima; in quelle aree -rmap ha ancora una buona prestazione.
Ciò significa che i benchmarks probabilmente non mostreranno nessun grosso vantaggio di rmap sulle VM standard, ma rmap assicurerà che il vostro server potrà sopravvivere meglio se viene eseguito. Ripristina il buon comportamento in un numero di altre situazioni in cui la normale VM va proprio a pezzi, notevolmente la maggior parte della gente ha riferito di un desktop che risponde meglio con rmap. Se lo si vuol provare, si può scaricare la patch di rmap al sito http://surriel.com/patches/ oppure accedere al bitkeeper tree su http://linuxvm.bkbits.net/.
Come pensi di risolvere il problema degli swap storms su macchine dotate di poca RAM sottoposte ad alto carico?
Beh, cominciamo con una brutta notizia: non c'è una VM magica. Se i tuoi programmi hanno bisogno di più RAM di quella disponibile e la richiedono tutta in una volta, non c'è niente che la VM possa fare. Dopotutto, se chiedono solo piccole quantità alla volta, o se al momento hai piu programmi che "girano" e alcuni di loro hanno abbastanza spazio in RAM, ci sono alcune probabili soluzioni. Se hai un programma che la maggior parte delle volte ha bisogno di meno RAM rispetto a quella disponibile, la VM può far funzionare il computer decentemente semplicemente scegliendo le giuste pagine da swappare. Se hai, per esempio, 5 programmi ed ognuno ha bisogno del 30% della ram, l'unica possibile soluzione è di non farli girare assieme.
Fortunatamente qui la VM può venire in aiuto: può attivare due processi per un pò, e poi riattivarne altri 2 a turno. Cosi ogni processo può avere una chance di funzionare alla massima velocità per un pò. Al momento l'unica parte implementata nella -rmap è una migliore selezione delle pagine da swappare. Fermarsi temporaneamente quando il carico diventa troppo alto, è una soluzione su cui devo ancora lavorare. C'è anche un terzo meccanismo, che è già presente in parte. Quando il sistema ha poca ram libera, semplicemente non usiamo una "lettura preventiva". Questo permette che, mentre il nostro I/O da disco è lento, le pagine che stanno in RAM ci possano stare un pò più a lungo.
Qualcuno pensa, come possibile soluzione per l'attuale problema della VM con alto carico, di passare a una paginazione locale, quando il numero delle pagine libere è... diciamo il 15% maggiore dispetto alle freepages.low, in modo da stare sicuri che ogni progesso abbia almeno il suo "working set" in memoria. Qual è la tua opinione in merito?
Questa soluzione è spesso proposta da persone che non pensano al problema. Ad ogni modo, non ho mai trovato nessuno capace di spiegarmi esattamente come quella "soluzione" possa risolvere il problema. Questa è uno delle noie minori dello sviluppo della VM, centinaia di persone vengono da me con "soluzioni" che loro stessi non capiscono come possano funzionare o persone che non hanno nessuna cognizione del problema. Ogni tanto portano buone idee, ma la maggior parte delle volte è sempre la stessa soluzione. Se sei interessato nel discutere queste idee, sei benvenuto su #kernelnewbies sul server irc.openprojects.net, ma non pensare di essere il primo ad avere una particolare idea, perché la maggior parte delle volte non lo sei. ;)
Cosa mi dici del progetto Kernel newbies? Quanto tempo ci passi su?
Kernelnewbies è un progetto per insegnare alla gente il kernel hacking, e come il kernel funziona. Il progetto è orientato sul kernel Linux, ma naturalmente le discussioni sugli altri kernel sono benvenute. Se la gente vuole imparare di più sul kernel, può andare su http://kernelnewbies.org/ o su IRC, in #kernelnewbies di irc.openprojects.net . Il progetto Kernelnewbies sembra che abbia "cresciuto" alcuni nuovi kernel hackers e testers durante in qualche anno. Il mio computer è sul canale IRC #kernelnewbies tutto il tempo e io stesso spesso passo il tempo su #kernelnewbies mentre faccio dei test.
Qual è la differenza tra la tua VM e quella di Arcangeli?
In quanti libri vuoi che ti risponda? ;) Beh, proviamo con una risposta breve. La VM di Andrea è un tentativo di migliorare le prestazioni della VM originale senza modificarne la struttura. Sembra che ci riesca molto bene, ma per via del fatto che non modifica la struttura, la sua VM soffre ancora degli stessi problemi di quella originale. La mia VM è un tentativo di risolvere i problemi alla base, ma senza concentrarmi ancora sulle migliorie alle performance.
Credo che la situazione che si era venuta a creare, cioè quella di avere due differenti tipi di gestione della VM sviluppati parallelamente su due kernel, fosse molto interessante, perché avrebbe permesso di prendere quanto di meglio dai due. Cosa ne pensi?
In un certo senso è vero, ma bisogna essere molto attenti sulla definizione di "migliore". Per alcuni, è "migliore" la VM che "gira" più velocemente in un limitato numero di condizioni. Per altri, è "migliore" la VM che permette al loro computer di funzionare, senza avere problemi nelle in occasioni di condizione critiche di VM. Devo ammettere che sia positivo avere idee opinioni differenti a proposito della VM. :)
Ognuno è libero di usare la VM che preferisce. Io penso che anche per questo venga chiamato "free software". :)
Questo è parte del free software. L'altra faccia della medaglia è che la gente è libera di mettere insieme le parti migliori dalle varie VM per realizzare sempre qualcosa migliore.
Certo. Alcune release del kernel ultimamente hanno sofferto di problemi di maturità (mi riferisco in particolare alla versione 2.4.11). Si tratta di pura casualità come penso io o credi che ci sia dell'altro?
Credo che il motivo principale sia dovuto al fatto che i bugreports e i bugfixes vengano persi ogni volta. Lo sviluppo del kernel di Linux avviene attraverso un meccanismo poco affidabile: la Linux kernel mailing list. D'altro canto, un bug database non può funzionare perché si riempirebbe di vecchi report in un batter d'occhio, come una mailing list. Per risolver il problema avremo bisogno di una nuova soluzione visto che l'unico sistema funzionante è quello in cui il vechio materiale scompare velocemente, altrimenti gli sviluppatori verrebbero semplicemente sommersi. Questo strumento potrebbe ritrasmettere i "pacchetti persi" tra le patch e controllare automaticamente se ancora sono applicabili. Il problema rimarrebbe per i bugreports, ma credo che sia inevitabile.
Così potrebbe essere più frequente in futuro?
Questo dipende da cosa fanno gli sviluppatori. Se ci fosse qualche sistema (sia tecnico che umano) per assicurare che le patch non vengano perse, credo che il sistema funzionerebbe meglio.
Credi che le misure previste nella DMCA possano influire nello sviluppo del Free Software? Mi riferisco in particolare alla decisione di non riportare nel CHANGELOG del 2.2.20pre11 i fix di sicurezza.
Potrebbe essere la fine dello sviluppo di software indirizzato all'utente, con il mondo che sviluppa software solo per massimizzare i profitti per i "distributori di contenuti". Al computer potrebbe succedere ciò che è successo alla TV, difficilmente si possono vedere programmi interessanti, e i rimanenti sono pensati per guidare lo spettatore tra i vari messaggi pubblicitari. D'altro canto, i computer sono degli strumenti molto potenti, e dubito che che la gente smetterebbe mai di sviluppare software solo perché Disney ha annunciato che vuole fare più profitti, quindi dubito che lo sviluppo di free software si fermerà.
Credo che la tendenza di Linux sia quella di favorire un'ottimizzazione per le macchine molto potenti (multiprocessore e con molta RAM). Sei daccordo con me?
No, per nulla. Il mercato dell'embedded sembra essere molto più attivo rispetto allo sviluppo di Linux su server di fascia alta. D'altro canto, i miglioramenti per quest'ultimi tendono a toccare molto più codice all'interno del kernel, mentre gli svilupattori di sistemi embedded tengono patch separate e non hanno piani di unire il loro codice con il "tree" ufficiale.
Non credi che questo possa essere un'ostacolo per la diffusione di Linux nel mercato desktop? Cosa manca ancora a Linux in questo senso?
Le due cose non sono correlate, il mercato desktop ha bisogno di applicazioni e non è realmente dipendente dal successivo sviluppo del kernel.
Credo che aver nominato come nuovo mantainer Marcelo Tosati sia stata una mossa intelligente: in questo modo sarà possibile per Linus e voi altri sviluppatori concentrarsi al meglio sul 2.5 in modo da non ripetere gli errori del 2.4. Cosa ne pensi della decisione di Linus?
Marcelo può essere in grado di evitare agli ultimi kernel 2.4 gli errori commessi ai primi, ma sono sicuro che qualcuno di essi verrà ripetuto nel 2.5. Linus aveva ragione quando ha detto che "[il suo] tree non è niente di speciale" e "Linus non sta al passo". è molto più conveniente e produttivo sviluppare in tree separati, così i bugfix possono essere integrati velocemente e Linus non è ulteriormente sovraccarico. Sospetto che sentiremo il bisogno di un sistema semiautomatico per mandare bugreports per codice già accettato da Linus, così Linus può comodamente scartare le patch quando non ha tempo, sapendo che gliele rispediranno di nuovo.
Il 2.5 si propone con una serie di obiettivi molto interessanti. Tu cosa stai preparando?
Sto lavorando per fare una VM migliore, non solo più scalabile su macchine più grandi, ma anche aggiustandola per le macchine più piccole. E più importante, I voglio fare una VM che non abbia problemi quando viene usata su un systema con un carico per il quale non è ottimizzato, voglio che sia robusta.
Ti ringrazio nuovamente per la gentilezza che hai avuto dandoci l'opportunità di conoscerti meglio.
Prego
Un ringraziamento particolare va a Clelia Ranaldo e a Claudio Martella per il prezioso contributo dato nella traduzione.
