Thema: Applikationen: Aufruf und ähnliches.

[Legend]

Nen neuen Task (also Scheduling) wählt die CPU für dich nicht aus ...
Das sind ein paar schnelle Movs gegen eine doch etwas komplexere Operation ... gute Frage.

[n3Ro]

Um die neue Task zu wählen wird doch dein Scheduler aufgerufen, und der liegt ganz bestimmt nicht im Userspace

[bluecode]

hi,

hier (englisch) wird erklärt warum software task-switching schneller ist. Messen kann mans auch durch den Time-Stamp-Counter in der CPU, da der jeden Prozessortick zählt (Zugriff mit rdtsc)
Ich finds außerdem einfachen! Und die Permission-Bitmap kann man ja trotzdem verwenden, da man so oder so ein TSS braucht.

[n3Ro]

hi,

hier (englisch) wird erklärt warum software task-switching schneller ist. Messen kann mans auch durch den Time-Stamp-Counter in der CPU, da der jeden Prozessortick zählt (Zugriff mit rdtsc)
Ich finds außerdem einfachen! Und die Permission-Bitmap kann man ja trotzdem verwenden, da man so oder so ein TSS braucht.

Em, naja, da steht wenn man es genauer betrachtet, dass der Hardware-Anteil an der Switching Zeit sehr lange im Vergleich zum Speichern und Laden der Register ist, und da die Hardware Switches (User nach Kernelmode, CR3 reload, Kernel nach User) sowieso auch beim Software Taskswitching durchlaufen werden, ist keinesfalls gesagt, dass es schneller sein muss.

[Legend]

Nun ja, andere Sache die mir grad aufgefallen ist: Was macht ihr mit der FPU usw. mit euren scheinbar favorisierten Task Gates auf dem Timer IRQ?

[n3Ro]

Das Handling der FPU ist bei beiden Methoden das gleiche: durch setzen des TaskSwitched-Flags im CR0 schmeißt die nächste FPU-Instruktion eine Exception, und man kann den alten Zustand wegsichern und den neuen laden ...

[Legend]

Hmm, interessante Methode, kannte ich noch nicht. Bin nur am Überlegen ob das bei manchen Anwendungen nicht langsamer sein könnte ...

[n3Ro]

Langsamer im Bezug auf was? Unter der Annahme, dass nicht jede Task die FPU benötigt und wenn, dann auch nicht immer, ist es immer noch schneller als bei jedem Taskwechsel den gesamten Context zu speichern und neu zu laden, welcher bei SSE immerhin schon 512 Byte groß ist! Und wenn nur eine Task die FPU benutzt hat, kann man es so regeln, das der Context nicht gespeichert und neu geladen wird, so spart man nochmal Zeit!

[SSJ7Gohan]

Wie kann man eigentlich mit Softwaretasking die FPU Register sichern? Bei jedem Taskswitch alle Register der FPU zu sichern ist ja viel zu langsam, gibt es da bessere Alternativen?

[joachim_neu]

Ich hab kein Taskgate auf das Timer IRQ. Bei der FPU hab ich 2 Ideen:

1. Die FPU wird beim Kernel beantragt und ab da speichert und läd der deren Ergebnisse zusätzlich aus dem TSS.
2. Der Task schickt eine Aufgabe per IPC an den Kernel oder einen FPU-Treiber, der führt sie aus und schickt das Ergebnis zurück.

Momentan favorisiere ich die 2. Idee, da sie nicht so komplex ist und nicht so weit ins System greift, dieses also so weit wie möglich abstrakt hält.

[SSJ7Gohan]

Naja, theoretisch ist das möglich, du musst aber bedenken, das alle Programme, die in C geschrieben sind und die FPU benutzen, nicht mehr richtig laufen werden, es sei denn, man schreibt einen eigenen Compiler, der beim verwenden der FPU (also des float oder double types) automatisch den FPU-Treiber aufruft. Die 2. Möglichkeit ist ja sehr viel langsammer, da wird es schneller sein, die Register immer zu sichern.

[n3Ro]

Also: der FPU/SSE Registersatz/Zustand hat NIX mit der TSS zu tun und wird KEINESFALLS automatisch gespeichert oder geladen, geschweigedenn automatisch umgeschalten. Deswegen gibt es die fsave und frstor bzw. fxsave und fxrstor Befehle, womit man das ganze per Hand speichern und laden muss, egal ob Hardware oder Software Taskswitching. Deswegen hat dieses nette TaskSwitched Flag in CR0 Einzug gehalten, und führt wie gesagt dazu, dass FPU/SSE Befehle eine Exception auslösen, wenn es gesetzt wird. Beim Hardware Taskswitching wird es nur automatisch gesetzt!!!!!Das "Beantragen" der FPU ist außerdem die Exception, die ein FPU Befehl dabei auslöst (hier haben sich die Chip Designer mal wirklich etwas sinnvolles augedacht).@j!n:  Ein FPU Treiber ist eine grandios langsame Idee, aber die Umsetzung würd ich mir doch gerne anschauen wollen, vor allem wie "unkomplex" diese sein soll.

[Legend]

Langsamer im Bezug auf was? Unter der Annahme, dass nicht jede Task die FPU benötigt und wenn, dann auch nicht immer, ist es immer noch schneller als bei jedem Taskwechsel den gesamten Context zu speichern und neu zu laden, welcher bei SSE immerhin schon 512 Byte groß ist! Und wenn nur eine Task die FPU benutzt hat, kann man es so regeln, das der Context nicht gespeichert und neu geladen wird, so spart man nochmal Zeit!

Ja, da war ich am überlegen wie viele Programme wohl die FPU brauchen würden.

[SSJ7Gohan]

Wann wird denn eine Exception ausgelöst, wenn man einen FPU Befehl nutzt? Muss man dazu ein spezielles Bit setzen?

[Legend]

Steht doch oben!
Dieses TaskSwitched-Bit oder wie das hiess!

[n3Ro]

Ganz genau steht es übrigens im System Programming Manual für IA32 von Intel in den Kapiteln über MMX und SSE