Autor Thema: Geschwindigkeit verschiedener Syscall Versionen  (Gelesen 5792 mal)

Sannaj

  • Beiträge: 103
    • Profil anzeigen
Gespeichert
« am: 26. October 2013, 00:48 »
Mich würde mal interessieren, wie lange genau so verschiedene Syscallvarianten so brauchen. Also Interrupts, CallGates, Sysenter/Sysexit bzw. Syscall/Sysleave.

Weil für mich sehen Call Gates eigentlich ziemlich cool aus.

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #1 am: 26. October 2013, 01:00 »
Das kommt immer auf die CPU an, und inwieweit sich die Handler für die unterschiedlichen Methoden unterscheiden, u.a. welche Register werden wie gesichert, woher kommt die Rücksprungadresse, etc. Mir sind keine Messungen bekannt, deswegen müsstest du wohl selbst mal welche anstellen. Und falls du das tust, kannst du ja deine Ergebnisse mal mit uns teilen. ;)

Weil für mich sehen Call Gates eigentlich ziemlich cool aus.

Ist nicht neuer = besser? Sysenter bzw. syscall sollten doch irgendeinen Sinn haben, wenn man sie zusätzlich zu Interrupts und Call Gates einführt. Weniger Overhead bei der Überprüfung der Privilegien zum Beispiel.
« Letzte Änderung: 26. October 2013, 01:02 von Jidder »
Dieser Text wird unter jedem Beitrag angezeigt.

Sannaj

  • Beiträge: 103
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 26. October 2013, 01:54 »
Naja CallGates haben schon ein paar Vorteile: 1. Deutlich flexibler als sysenter, da sie a) auch auf älteren Systemen und bei flexibeler GDT sowie bei AMD und Intel gleichermaßen laufen. Dadurch kann man sie als Standard-Api verwenden. b) man sich nicht um die Sicherung der Rücksprungadresse kümmern muss (was insbesondere wertvolle Prozessorregister dann spart, wenn man sie nicht auf dem Stack sichern kann.), c) man kann mehre davon haben. d) Man kann Einträge vom User auf den KernelStack kopieren lassen. e) Sie geraten sicherlich in keinen Konflikt mit irgendeiner anderen Api. f) wenn man ganz geschickt ist, kann man im nicht verwendeten Call-Bereich des Aufrufs noch Informationen verpacken, die auch vom Kernel angesteuert werden können.

Gegenüber Interupts, ist der Vorteil, dass sie alles können, was SoftwareInterrupts können, nur schneller. Callgates poppen keine Flags, ob das gut oder schlecht ist sei mal dahingestellt. Der einzige Nachteil ist, das der Opcode halt bei Interrupts immer 2 byte lang ist und bei CallGates im 32 Bit Modus 7 Byte lang ist. (Wobei man hierbei wie gesagt, da auch irgendetwas reinschreiben kann.)

Jidder

  • Administrator
  • Beiträge: 1 625
    • Profil anzeigen
Gespeichert
« Antwort #3 am: 26. October 2013, 02:18 »
Die gelisteten Punkte stimmen zwar (soweit ich das sagen kann), aber sie haben nichts mit Performance zu tun. Der Geschwindkeitsvorteil gegenüber Interrupts ist vermutlich vernachlässigbar. Die Flags landen beim INT sowieso im Cache bzw. werden beim IRET daraus gelesen.

Der entscheidene Nachteil von Interrupts und Call Gates ist, dass die halt die aufwändigen Checks von CS und SS durchführen und in der GDT und ggf. der TSS rumlesen, und deswegen langsamer als SYSCALL bzw. SYSENTER sind. Und ich vermute niemand nimmt Call Gates statt Interrupts, weil die einzelnen Handler vermutlich sehr viel gleichen Code haben. Es macht mehr Sinn, das, was alle Systemaufrufe gemeinsam haben an einer einzelnen Stelle zu haben, und anhand eines Registers die Funktion zu unterscheiden anstatt für jeden Handler eine Funktion zu haben.
Dieser Text wird unter jedem Beitrag angezeigt.

Sannaj

  • Beiträge: 103
    • Profil anzeigen
Gespeichert
« Antwort #4 am: 26. October 2013, 10:06 »
Jo das Stimmt. Ich hab mal nachgeschaut. Auf der 486 war call (callGate) Aufruf ohne Stackparameter gerade mal 2 Takte schneller als ein Interrupt. Ähnliches gilt für die Rückkehrbefehle, auch hier ist die CallGate nur 3 Takte schneller. Ist schon schade, weil CallGates sahen wirklich gut aus. Wahrscheinlich ist es wirklich am Elegantestes, eine Page für Syscalls anzulegen, auf die dann als Funktionen zurückgegriffen werden kann, und die dann den eigentlichen Ringwechsel durchführen, indem sie Syscall/Sysenter oder was auch immer benutzten. (Dann bräuchte man sich die Rücksprungadresse nicht explizit zu merken.). Aber wie gesagt, das ist sehr eng, wenn man viele Parameter an den Kernel senden will.
« Letzte Änderung: 26. October 2013, 10:23 von Sannaj »

 

Einloggen