Da die Implementierung noch nicht vollständig abgeschlossen wurde, kann ich an dieser Stelle nur Abschätzungen zur Performance der Gerätetreiber innerhalb des DDE geben.
Ein Faktor, der die Leistung -- genauer die Latenz -- beeinflußt, ist der Ansatz eines Omega0-Servers. Da in Mikrokernen Unterbrechungsereignisse per IPC zugestellt werden, sind Verzögerungen bis zum acknowledgement in diesen Systemen größer als bei monolithischen Ansätzen. Der Omega0-Server verschärft dies, in dem er noch eine Indirektionsstufe zwischen Interruptquelle und Treiber einführt. Somit sind für jeden Interrupt zwei IPC-Nachrichten bis zum Treiber-Server nötig.
Die Synchronisation im DDE basiert auf den standard Lock- und Semaphore-Implementierungen. Diese nutzen atomare Operationen und im Blockierungsfall IPC. Dadurch ist zumindest das Blockieren und Aufwecken aufwendiger als in Linux -- es bedarf zwei IPC-Nachrichten.
Weiterhin ist eine zusätzliche Verzögerung zu erwarten, wenn der Kern-Speicherpool vollständig belegt ist. Hier müssen von der morecore() Funktion neue Dataspaces angefordert und dem Pool zugeführt werden. Dieser Vorgang beinhaltet mehrere IPCs innerhalb der L4-Task (region mapper) und nach außen (dataspace manager). Vermindern kann man diese Auswirkungen, in dem man eine Analyse des Speicherbedarfes des Gerätertreiber-Servers durchführt und die Größe des initialen Pools entsprechend den Ergebnissen anpaßt.
Insgesamt gesehen ist der Faktor IPC sehr wichtig in mikrokernbasierten Systemen. Da der L4- bzw. Fiasco-Mikrokern eine schnelle IPC zur Verfügung stellt, ist zu erwarten, daß der Einfluß der Architektur auf die Leistung nicht sehr groß ist.