Inside Leopard. Capitolo 1: Kernel

La nostra analisi sul kernel di Leopard parte da alcune accese discussioni e congetture di poco più di un anno fà, quando diversi articoli iniziarono a lamentare il mancato rilascio della versione x86 del kernel di Tiger insieme alla controparte PPC. Le illazioni vennero ancor più alimentate dalla stessa Apple che si rifugiò in una chiusura apparentemente ingustificata.
Tra le ipotesi più ottimistiche c'era anche quella di una completa riscrittura del kernel che avrebbe potuto portare, tra le altre novità, anche una migliore gestione della virtualizzazione (ipotesi che traeva sostegno anche dal rilascio dei nuovi processori in grado di supportare via hardware questa opportunità).

In realtà molte di queste fantasie sono nate dal presupposto che il kernel di Mac OS X difetti in performance, cosa principalmente dovuta a scelte errate di progettazione (qui in verità entriamo in una delle più grandi discussioni teoriche sull'ingegneria informatica, ovvero la questione dei microkernel, da cui ci terremo abbastanza alla larga. Per i più curiosi ecco un link d'esempio).
Questo genere di discussione è stata spiegata molto bene in una delle sessioni dello scorso WWDC in cui gli ingegneri del core hanno espressamente detto che il loro scopo è quello di migliorare le parti critiche che possono effettivamente dare un miglioramento agli strati superiori del sistema: tutto quello che non si traduce in un miglioramente visibile (non i microbenchmark) da parte degli utenti/sviluppatori è cosa non primaria nello sviluppo.
Questo non significa certamente che il team di ingegneri non sia competitivo; piuttosto si è cercato di guardare il problema da un different punto di vista che non sia quello di Linux con LMBench o di Solaris con libmicro.

Con l'arrivo di Darwin 9, Apple ha quindi proseguito nel miglioramento dello scheduling di sistema (a proposito dello scheduling vi rimando a questi vecchia articoli) e della latenza. C'è quindi una bella differenza nel dire "il sistema è veloce" e "il sistema è responsivo": vediamo quindi qualcuna di queste novità che ci aspettano in Leopard.

Un'altra novità che non riguarda strettamente il kernel è l'annuncio dato circa le "vecchie" API Carbon: da oggi in avanti le nuovi API della GUI saranno disponibili soltanto per Cocoa, mentre il package Carbon riceverà soltanto bug fixes. Una notizia molto importante e delicata che porta con se l'inizio del vero addio al vecchio Mac OS.

Lo scheduling e la responsività
Come ci si potrebbe aspettare dando uno sguardo al nuovo hardware (che sempre più si sposta verso il multicore) le applicazioni sotto Leopard benificeranno molto di una migliorata architettura per lo scheduling su più processori/core. La lista piatta delle code dei processi si è trasformata in una struttura a coda gerarchica che permette una migliore scalabilità rispetto all'hardware e alle scelte dello scheduler.

Anche la sezione della memoria virtuale ha beneficiato di molti cambiamenti: ora il kernel riconosce meglio quale parti di memoria sono attualmente usate dall'applicazione attiva e quali sono sicure da poter essere swappate sul disco in caso di bisogno. Inoltre nel caso in cui sia necessario swappare porzioni di memoria sul disco Leopard creerà dei file di swap dinamici anzichè dei documenti statici di supporto.

Sono aumentati anche il numero di processi per utente (passati da 100 a 266) e il numero di file massimo che un processo può aprire.

Il nuovo Darwin possiede anche un nuovo sistema di sandbox che forza alcuni processi ad essere eseguiti soltanto in ambiente sicuro (e quindi permette di estendere in modo dinamico le regole di sicurezza del kernel stesso). L'implementazione di Apple è basata su MAC, Mandatory Access Control; le definizioni delle regole per l'applicazione sono definite in semplici file di testo, come nella migliore tradizione Unix, contenuti in /usr/share/sandbox. Apple utilizza questa funzionalità già in parecchie applicazioni tra cui Bonjour, QuickLook e Spotlight.

DTrace per il debugging
Una dei più grandi cambiamenti che riguardano il kernel di Leopard è sicuramente l'aggiunta di DTrace, un altro progetto opensource costruito da Sun. Continua quindi la tradizione di attingere e migliorare basi già esistenti e consolidate per farle proprie.

DTrace è un framework per il tracciamento dinamico delle attività svolte dal sistema operativo. Per capire meglio proviamo a pensare ad uno sviluppatore che lavori ad una parte del Kernel o ad esso strettamente legata.

Per aiutarsi nel debug del codice, il nostro ingegnere inserirà nelle parti critiche una sorta di controllo di notifica che dice più o meno "Se ho impostato il debug stampa questa informazione di supporto". Il problema più grosso di una implementazione di questo genere è proprio quello delle performance: benchè si tratti di piccoli controlli che richiedono un millisecondo per essere verificati, il kernel per definizione contiene codice che viene eseguito più spesso e che deve essere quindi molto veloce.
Si tratta poi di ricompilare il kernel e provare di nuovo finchè il codice sarà stabile. A quel punto si potranno togliere i codici di debug (ma siamo ancora sicuri che non possano esserci altri problemi?).
Chiamare una routine del genere molte centinaia di volte al secondo chiede quindi molto più di un millisecondo. E se ora inseriamo centinaia di questi controlli nel codice probabilmente ci ritroveremo a misurare in ordini di grandezza più grandi...e più lenti.

In una situazione del genere (volutamente semplificata ma realistica) DTrace può fare la differenza poichè sopperisce quasi completamente ad entrambi i problemi appena descritti: innanzitutto non c'è alcun bisogno di ricompilare il kernel e riavviare (il debugging può essere avviato o terminato anche a kernel attivo), inoltre quando il debug è disabilitato (ogni punto di debug è chiamato anche sonda) il suo impatto sul sistema è pressochè nullo (sarà quindi possibile tenere i codici di debug).
DTrace si compone di un suo linguaggio (il D, ma non è quello famoso, ha una sintassi simile a quella dell'awk e non è quindi un linguaggio puramente procedurale, ma del tipo "pattern action", dove il pattern è un modo per selezionare alcune sonde e/o alcuni risultati particolari delle sonde, mentre con l'action si identificano le attività necessarie per elaborare le informazioni reperite) semplificato in grado di definire le condizioni, che non supporta ne subroutines, loops etc ma che soltanto delle funzioni base in grado di tracciare le notifiche.

Il framework è composto da tre componenti principali:

• una serie di sonde (probe) introdotte nel kernel di Solaris 10 OS, che possono essere o meno attivate, descritte in dtrace(7D);
• una libreria di interfacciamento per accedere dallo spazio utente alle funzionalità del framework, libdtrace(3LIB);
• alcuni comandi utente che permettono di accedere in modo completo alle informazioni che sono rilevate, su richiesta, dalle sonde, tra cui il comando, omonimo del framework, dtrace(1M).

DTrace è capace di cercare e identificare i problemi che affliggono una rete e riportarli in minuti. E' progettato specificatamente per essere usato in tempo reale nei sistemi di produzione. DTrace, che usa più di 30.000 punti di monitoraggio solo nel kernel, permette agli amministratori di guardare l'intero sistema in un nuovo modo, rivelando i problemi sistemistici che erano prima invisibili e risolvendo i problemi di prestazioni.

Gli script di DTrace sono dei semplici file di testo e se per la maggior parte degli utilizzatori e sviluppatori di Mac OS X non aggiungerà molto all'esperienza quotidiana, è un ottimo strumento per semplificare lo sviluppo e il perfezionamento dei pilastri del proprio OS.

Instruments per le performance
Probabilmente la vostra prima impressione aprendo Instruments sarà quella di trovarvi difronte ad una sorta di GarageBand o qualche altra strana iApp. In realtà Instruments (o per chiamarlo con il vecchio nome delle prime pre-release XRay) è un ottimo strumento per debuggare ed analizzare i vari aspetti (I/O, CoreData, Directory Attributes etc.) dalle semplici applicazioni fino all'intero sistema operativo. Molto di quello che offre Instruments è basato proprio su DTrace che abbiamo appena visto.
Le analisi fornite da trace vanno da un semplice "quanti file vengono aperti allo startup dell'applicazione" fino alle statistiche sulle funzioni più chiamate etc; insomma un ottimo strumento per individuare colli di bottiglia durante lo sviluppo di software e rendere le applicazioni più stabili e performanti.

Il Kernel
Con l'arrivo di Tiger più di un anno fà, Apple ha terminato la transizione dal vecchio core NeXT verso le nuove fondamenta di Mac OS X "limando" le imperfezioni delle vecchie API del kernel.
In Leopard l'implementazione di DTrace ha dato il via ad una nuova fase transitoria che porterà i suoi frutti a maturazione soltanto con la prossima major release.
L'uso di DTrace ha permesso infatti di ottimizzare le performance e aumentare la scalabilità in maniera tale da rendere lo stesso Mac OS X molto più veloce rispetto alle precedenti release; ma questo è solo il primo passo, ci sono ancora tutte le applicazioni da coprire.

Approfondimenti:
OpenSolaris Dynamic Tracing Guide (DTrace)
DTrace Community
Darwin Sources
Ars Technica

[tags]Kernel Leopard, Changes in Leopard Kernel, 10.5 Kernel[/tags]

• No Related Post