Thema: RPC-Performance

[kevin]

bluecode hat mich grad aus Versehen im IRC daran erinnert, dass ich mal gesehen habe, dass tyndur beim Durchführen der RPCs ein paar komische Sachen machen, die Performance kosten könnten. Konkret erinnere ich mich, dass der Ablauf für den synchronen Fall irgendwie so aussieht:

Code: [Auswählen]

Anfrage senden ------------------> (spezifischer RPC-Handler)
                                               |
(Antworthandler) <----------------  Antwort senden
      |
(Handler fertig) ---------------->  (Handler fertig)
                                               |
Antwort verarbeiten <--------------------------+
Die Pfeile nach links/rechts sind dabei jeweils ein Taskwechsel. Das geht mit Sicherheit besser. Und ich könnte mir vorstellen, dass man bei genauerem Hinschauen noch mehr Fälle findet, wo die Kommunikation umständlicher als nötig ist.

Hat zufällig jemand Lust, sich das näher anzuschauen und den Code entsprechend zu verbessern? Unterstützung im Forum und/oder IRC ist natürlich inklusive.

[erik.vikinger]

Hallo taljeth,


du erinnerst Dich doch bestimmt noch an das http://lowlevel.brainsware.org/forum/index.php?topic=2321.msg26297#msg26297.
Bist Du wirklich der Meinung das da etwas "dran rum werkeln" hilft?
Ich hatte damals schon so den Eindruck das Du mit dem derzeitigem tyndur-Konzept nicht so wirklich zufrieden bist.

Ich würde mich eventuell für eine Neuimplementierung (mit einem frischerem Konzept) zur Verfügung stellen, als Übung für mein eigenes Projekt quasi.
Du kannst Dir ja mal mein Konzept bei http://lowlevel.brainsware.org/forum/index.php?topic=2433.0 genauer anschauen und mir sagen ob Dir sowas eventuell gefallen könnte. Ich würde auch eine Umsetzungsschicht vom derzeitigem tyndur-Konzept drüber basteln, für Kompatibilität und sanftem Umstieg.


Wir können auch gerne über was anderes Diskutieren, aber das derzeitige IPC-Konzept von tyndur würde ich an Eurer Stelle lieber beerdigen als noch ewig dran rum zu werkeln.

Überlegt es Euch mal, ich bin auch nicht traurig wenn Ihr nein sagst.


Grüße
Erik

[kevin]

Cool, danke!

Danach zu fragen, es wirklich ganz grundlegend umzubauen, habe ich mich gar nicht getraut, weil das ja schon ein bisschen was an Arbeit ist. Dann werde ich mir bei Gelegenheit dein Konzept doch nochmal genauer anschauen (und FreakyPenguin dazu überreden, das auch zu tun ). Wie wir das mit dem sanften Umstieg im Detail hinkriegen, müssen wir halt noch schauen - es könnte langsam holprig werden, wenn wir überall gleichzeitig Großbaustellen aufmachen. Aber irgendwie kriegen wir das schon hin.

[erik.vikinger]

Hallo,

Cool, danke!

Zu meiner Sicherheit: bevor ich verbindlich zusage wüste ich natürlich gerne so ungefähr wie viel Arbeit ich mir da eigentlich aufhalsen tät.

Ist Dir eigentlich schon aufgefallen das mein Konzept Threads voraussetzt?
Wenn das nicht zusagt können wir uns auch gerne über ein anderes Konzept unterhalten.


Grüße
Erik

[kevin]

Wieviel Arbeit es wird, sieht man meistens erst, wenn man merkt, was doch nicht so einfach funktioniert, wie man sich das gedacht hat.

Aber grundsätzlich müsstest du ja im Moment dein Konzept besser kennen als ich. Das war das mit dem "Popupthreadpool", wenn ich das mal so nennen darf, oder? Kernelseitig sollten Threads theoretisch funktionieren, sind aber nicht gut getestet. Userspaceseitig wäre da wohl noch ein bisschen was zu machen, insbesondere in Sachen Locking. TLS brauchst du nicht, oder?

[erik.vikinger]

Hallo,

Wieviel Arbeit es wird, sieht man meistens erst, wenn man merkt, was doch nicht so einfach funktioniert, wie man sich das gedacht hat.

Ahja, natürlich.

Das war das mit dem "Popupthreadpool", wenn ich das mal so nennen darf, oder?

Das darfst Du gerne so nennen. Ich hab zu diesem Konzept in einem Buch mal was gefunden, ich glaub das war sogar jenes von Tannenbaum, aber das war nur ein kleiner Abschnitt mit ein paar wenigen grundlegenden Betrachtungen dieses Konzepts.
Das mit dem Pool ist kein muss sondern eher ein Feature das der Performance dient, es geht auch ohne aber dann natürlich deutlich langsamer.

Kernelseitig sollten Threads theoretisch funktionieren, sind aber nicht gut getestet. Userspaceseitig wäre da wohl noch ein bisschen was zu machen, insbesondere in Sachen Locking.

Also für mein Konzept muss der Kernel mindestens folgendes bieten:

• allozieren von physischen Speicher (muss nicht zusammenhängend sein) um ihn zu einen späteren Zeitpunkt schnell in den virtuellen Adressraum eines Prozesses einfügen zu können (dann natürlich am Stück)
• Shared-Memory, also virtuellen Speicher eines Prozesses in den virtuellen Speicher eines anderen Prozesses einzublenden (eventuell mit geänderten Attributen wie Read-Only), es ist dann auch wichtig wenn der "erbende" Prozess diesen Speicher seinerseits an andere Prozesse weiter "vererben" kann
• Threads, die aus User-Mode-Prozessen benutzt werden können, der IPC-Mechanismus wird aber einige Kernel-Interne Funktionen (Thread erstellen, zerstören u.ä.m.) direkt aufrufen
• vernünftige Verwaltung mehrerer Stacks in einem Prozess (ist für Multi-Threading auch eigentlich unerlässlich)

(das alles natürlich für ein Flat-Memory-OS)
Die meisten meiner SYSCALLs haben sehr viele Parameter (und oft auch mehrere Rückgabewerte), hier müsste man sich für x86 was passendes überlegen.

Falls es auch Kernel-Threads geben soll, in was für einem Kontext die dann laufen sollen verstehe ich dabei allerdings (noch) nicht, dann bedeutet dass das an etlichen Stellen im IPC-Code passend unterschieden werden muss. Ich persönlich finde das ungeschickt.

TLS brauchst du nicht, oder?

Nein, TLS brauch ich dafür nicht.

Dann werde ich mir bei Gelegenheit dein Konzept doch nochmal genauer anschauen (und FreakyPenguin dazu überreden, das auch zu tun).

Ja, bitte tut das.


Grüße
Erik

[kevin]

Threads, die aus User-Mode-Prozessen benutzt werden können, der IPC-Mechanismus wird aber einige Kernel-Interne Funktionen (Thread erstellen, zerstören u.ä.m.) direkt aufrufen

Da müssten wir die Funktionen noch als Syscalls exportieren. Kann ich bei Gelegenheit machen - oder möchte das irgendein anderer übernehmen? Das wäre eigentlich eine klassische Einsteigeraufgabe ohne größere Schwierigkeiten. Im Bereich Threading könnte man anschließend auch gleich weitermachen und die libc threadsafe machen.

Hat irgendjemand Interesse bevor ich die Aufgabe selbst wegschnappe?