DragonFly BSD

Da Wikipedia, l'enciclopedia libera.

Dragonfly BSD è un progetto di un sistema operativo per macchine multiprocessori che deriva da FreeBSD 4, nato grazie all'idea di Matthew Dillon perché non era soddisfatto del metodo con cui FreeBSD gestiva i sistemi multiprocessori, attraverso SMPng (derivato dal codice di BSD/OS 5). Ci sono attualmente cinque sistemi BSD open source e la loro differenza sta tutta nel target:

FreeBSD- velocità ed affidabilità su i386,
NetBSD- portabilità,qualità del codice,
OpenBSD- sicurezza e crittografia,
DragonFly BSD- prosegue il ramo 4.x di FreeBSD,
MacOS X- è il sistema operativo della Apple,
BSD/os- la versione commerciale.

Il progetto DragonflyBSD è stato annunciato nel giugno 2003. La base di codice è stata presa dal rilascio 4.8 di FreeBSD,che ha offerto le prestazioni migliori e le caratteristiche più complete. Si è scelto di utilizzare un'architettura che tenesse conto della differente velocità di accesso alle memorie presenti in un sistema, quali cache e RAM (Random Access Memory), che è di fondamentale importanza nella realizzazione di sistemi multiprocessore. Questa architettura è denominata NUMA (Non Uniform Memory Access)e consente l'utilizzo di un sistema con un elevato numero di vie velocizzando il transito dei dati tra CPU e memoria. Dragonfly supporta processori della famiglia x86 ma il lavoro è anche indirizzato a supportare i nuovi processori a 64bit della AMD. La filosofia di Dragonfly è la suddivisione esplicita del lavoro tra i processori, ovvero significa che un processo non sarà mai trasferito su un'altra CPU permettendo quindi di utilizzare al meglio i dati contenuti nella cache e senza dover effettuare il lock. DragonflyBSD è sviluppato da molta gente intorno al mondo. Non c'è processo di qualificazione; chiunque può presentare il suo codice, documentazione o disegni per uso nel progetto.

Indice

1 Kernel
- 1.1 La comunicazione in Dragonfly
- 1.2 La gestione in Dragonfly
2 Collegamenti esterni

[modifica] Kernel

DragonflyBSD è il primo BSD OS non basato su Mach ad adottare un'architettura a kernel ibrido,ovvero che il kernel condivide i concetti e i meccanismi d'architettura sia monolitici che delle tipologie micro.Il modello LWKT (Light Weight Kernel Threading) funziona associando ogni processo ad un thread. Ogni CPU ha il proprio scheduler LWKT. In questo modo i thread sono assegnati ad una specifica CPU permettendo così la gestione senza la necessità di utilizzare un lock MP. Inoltre,grazie alla protezione di memoria,un thread non può essere spostato su un'altra CPU da un thread a priorità maggiore e le applicazioni non interferiranno mai tra di loro. La gestione dei thread utente viene effettuata da uno scheduler dedicato, chiamato Userland e la sua esecuzione è regolata, anche nell'eventualità di un interruzione,dai dati contenuti nella cache.

[modifica] La comunicazione in Dragonfly

La comunicazione attuata nella maggior parte dei sottosistemi comunicativi di Dragonfly avviene attraverso l'IPI. Questo sistema è utilizzato per suddividere thread e memoria libera sulle altre CPU. I messaggi generati da quest'ultime sono costituiti da una chiamata avente un puntatore a funzione e i dati relativi che la CPU destinataria eseguirà in modo asincrono.In questo modo si avranno grandi vantaggi dal punto di vista della performance, in quanto la CPU chiamante non attenderà l'esecuzione della CPU destinataria.La ricezione di un messaggio IP da parte di una CPU prevede la sospensione del thread attualmente in esecuzione rendendolo non bloccabile.

[modifica] La gestione in Dragonfly

La gestione dei kernel thread avviene attraverso lo Slab Allocator,un sottosistema che permette l'accesso a porzioni di codice critico senza negare alle altre CPU l'utilizzo del restante kernel. In altre parole,quando una CPU ha bisogno di utilizzare una parte del kernel, blocca con un lock globale l'accesso al kernel per il tempo necessario ad escludere quella determinata sezione dall'esecuzione da parte delle altra CPU. Questo processo prevede che lo slab allocator di ogni CPU abbia a che fare con 128k di kernel che poi verranno distribuiti e suddivisi in aree più piccole in base alla richiesta dei thread.