%*
%* Copyright (c) 2007 by Lukas Ruf (lukas.ruf@lpr.ch)
%*
%* Create: 2007-01-30:1643
%* Modify: 2007-01-30:1644
%* Commit: $Id: outlook.tex 3053 2007-08-20 19:32:27Z sryffel $
%*


\chapter{Weiterführende Arbeiten}
\label{outlook}

% That's not a well-known erroneous mail client.
% 
% But document what your achievements might be good for.  What
% others could do with them.

Im Zuge dieser Arbeit ist viel Code entstanden und Topsy v3 ist der 
Vision der Multicore Unterstützung einen Schritt näher gekommen. Es sind aber
noch viele Verbesserungen möglich. Die aus meiner Sicht
wichtigsten Punkte will ich in diesem Kapitel aufführen, ohne dabei die in
\cite{bib:topsyv3} genannten Punkte zu wiederholen. 


\section{Multicore}

Bis Topsy v3 effektiv auf mehreren Prozessoren läuft, braucht es noch ein paar
Erweiterungen. Die zusätzlichen Prozessoren müssen gebootet und verwaltet
werden. Die wichtigsten Änderungen sind diejenigen im Scheduler. Dieser sollte
überdacht werden. Es muss sich zeigen, ob das in \cite{bib:topsyv3}
vorgeschlagene hierarchische Scheduling für ein MultiCore Setup geeignet ist. 


\section{Gegenwärtige Limitierungen}

Topsy v3 hat noch Limitierungen, die in Zukunft adressiert werden müssen. 

Die ia32-Architektur ist zwar komplex, bietet dafür aber  mehr Features
als andere. Da die Autoren von Topsy v3 andere Zielplattformen im Auge hatten,
finden einige Funktionalitäten keine Entsprechung in Topsy v3.


\subsection{Memory Management}

Die ia32-Architektur kennt ein `Global' Flag für Pages, welches diejenigen
kennzeichnet, die bei einem Wechsel des virtuellen Adressraums nicht aus dem
Cache gelöscht werden müssen. 
% Sie dürfen schon gelöscht werden, dies ist aber nicht gut für die Performance,
% da beim nächsten Zugriff die physikalische Adresse wieder nachgeschaut werden
% muss. 
Man könnte die Performance steigern, indem Teile 
des Interrupt Handlings, die Hardware I/O Region und die Pages mit den APIC
Registern als global eingetragen werden.

% Das Memory Layout in Topsy v3 ist suboptimal, da noch zu viel Memory geshared
% ist. Man könnte in dieser Hinsicht Topsy v3 noch modularer gestalten. 
% Die Kernel Threads verwenden noch noch zu viele gemeinsame Datenstrukturen. 
% Diese Änderung müsste gleichzeitig mit dem, in \cite{bib:topsyv3} 
% vorgeschlagenen, Redesign des Build Prozesses vorgenommen werden.

% Folgende Aussage ist nicht korrekt:
% ``Dies gilt insbesondere für die User Threads, in deren Adressraum sich momentan 
%   noch das ganze Kernel Code und Daten Segment lesbar gemappt ist.''




\subsection{Thread Management}

Das neue Thread Management muss weiter optimiert werden. Ein wesentlicher
Vorteil von softwarebasierten Kontextwechseln ist die grössere Kontrolle über den
Vorgang. Es wäre von Vorteil, Kontexte vor dem Wechsel zu überprüfen und mehr
Statistiken über den Zustand des Systems zu führen.

Mit der Implementation der MultiProcessor Spezifikation \cite{bib:mpspec} werden
weitere Interrupts eingeführt. Spätestens dann sollten diese adäquat
priorisiert werden.


\subsection{Interprozesskommunikation}

Auf einige unwahrscheinliche Spezialfälle reagiert Topsy v3 noch nicht optimal.
Dazu gehört unter anderem das Versenden einer Nachricht an einen nicht
existierenden Thread (siehe Kapitel \ref{evaluation:results:random}). Wenn ein
Thread versucht, einem anderen mit voller Nachrichten Queue eine Nachricht zu
schicken, wird er beendet, sofern er ein User Thread ist. Anderenfalls
passiert nichts und die Nachricht geht verloren. Beides entspricht nicht dem
Verhalten eines fehlertoleranten Systems. Die Zustellung könnte zum
Beispiel später nochmals versucht werden.

Topsy v3 wurde 2002 entworfen, als Computer im Allgemeinen und Kopieroperationen
im Speziellen noch viel langsamer waren. Tests ergaben dazumal, dass ab einer
Nachrichtengrösse von 16Bytes das Anhängen einer Enveloppe performanter als das
Kopieren der ganzen Nachricht war. Dies ist heute sicher nicht mehr der Fall.
Viele Syscalls müssen für wenige zusätzliche Bytes eine Enveloppe verwenden.


\subsection{Input/Output Subsystem}

Aus Zeitmangel wurden nur der Tastatur- und Video-Treiber portiert. Die anderen
müssen eventuell noch angepasst und getestet werden.

Der Tastaturtreiber und andere verwenden zum Lesen und Schreiben einzelner
Zeichen eine Enveloppe. Dies ist ein grosser Overhead und könnte durch die
Unterscheidung zwischen Zeichen- und Block-Geräten vermieden werden.


\subsection{User Threads}

Um den Tastaturinput zu lesen, muss die Shell pollen. Eine bessere Lösung wäre,
der Aufrufer würde blockiert, bis ein Zeichen eintrifft. 

Von der Tastatur kommende Zeichen werden schon im Interrupt Handler auf die
Konsole geschrieben. Dies ist eigentlich unerwünscht und macht das nachträgliche
Editieren der aktuellen Kommandozeile schwieriger. Dies wäre aber eine sehr
praktische Funktion.



