Nachrichten

141

OS-Design / Re: Nicht unterbrechbarer Kernel

« am: 11. October 2011, 18:18 »

Auf einem typischen Desktop-PC ist es IMHO nicht so extrem ungewöhnlich das die CPU mal für ne halbe Sekunde nicht zur Verfügung steht so dass das restliche System eigentlich damit umgehen können sollte.

Also erstmal was ist denn für dich ein typischer Desktop-PC?

Ich erinnere mich daran, dass das Video oft am Audio synchronisiert wird und da weiß ich nicht wie das im Detail passiert und wieviel da gebuffert wird. Auch weiß ich nicht in wie weit man die Soundkarte Anweisungen mitteilen kann, hole in der und der Zeit von da und da Daten ab und spiele es dann ab (oder die Daten vorher schicken und sagen zu welchem Zeitpunkt es abgespielt werden soll).

Ich wollte Dir damit auch keine Alternative zu den vielen Kontextwechseln anbieten (wenn die Speicheroperation unterbrechbar sein soll dann gibt es eben teure Kontextwechsel)

Wie kommt ihr eigentlich darauf, dass da immer teuere Kontextwechsel passieren. Die können passieren, müssen aber nicht. Genauso wie die innerhalb eines Monolithen passieren können (wenn man keinen Spinlock hält und die Ints an sind).

Nur habe ich so den Vorteil das ich das viele Interrupt an und ausmachen (was auf älteren CPUs nämlich verdammt teuer ist und das bei meinem alten Spinlock-Code richtig oft passiert ist) auf einmal an und wieder ausmachen alle 512 Schleifendurchläufe reduziere.

Einen konzeptionell nichtunterbrechbaren Kernel dann doch wieder unterbrechbar zu machen und Thread-Arten ändern (inklusive zusätzlichen Stack allozieren) usw. ist mMn ein riesiger Haufen Code der vor allem jede Menge potentielle Bugs in Deinen Kernel holt.

Ich brauche eh Kernel-Threads, also sind die schonmal vorhanden und wie gesagt, das Thread-Art ändern besteht nur aus einem Pointer der entweder vorhanden ist oder nicht, mehr ist das nicht (so ist es jedenfalls geplant, ob da nicht doch noch Schwierigkeiten auftauchen weiß ich nicht).

Davon ausgehend das die Codezeilen-Anzahl bei beiden Varianten (einmal Schleife im Kernel und einmal im UserSpace) gleich sind, sind die Bugs doch eh statistisch gleich vorhanden Gut einmal werden sie dann im UserSpace sein, was die Sache aber nicht besser macht, weil es trotzdem ein wichtiger Systemteil bleibt.

Du kennst doch sicher das KISS-Prinzip.

Ja, aber ...

Wie man das nun interpretiert ist so eine Sache, es liegt auch immer im Auge des Betrachters. Das hatten wir doch erst, wozu dann nen Baum nehmen, der ist nun wirklich nicht mehr KISS, sondern die Liste oder das Array.

Die ganzen technischen Sachen sind nicht mehr KISS. Wenn man mehr Effizienz will, muss man leider oft auf KISS verzichten. Denn KISS wäre bei einem OS mMn ganz eindeutig ein nicht unterbrechbarer Monolith, aber wirklich effizient und praktikabel ist das nicht.

Das Du die INT-Nummer erst zur Laufzeit kennst ist doch gar kein Problem, zumindest für die User-Mode-Programme. Da bastelst Du ein kleines Assembler-Modul für die yield()-Funktion :

So ähnlich habe ich das schon gemacht, dass wäre nicht das Problem.

Edit::

Nicht das ich irgendwie eine schlechte Meinung vom Linux-Kernel hätte aber folgendes ist nicht in Ordnung:

freier RAM: 39mb= "8619*4kB 127*8kB 59*16kB 41*32kB 15*64kB 7*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 39604kB"

Sobald man jetzt zusammenhängende >128kb braucht startet der OOM Killer. Wenn ich mich recht entsinne liegt es daran, das im Kernel nur identity gemappt wird (??). Gut das ist jetzt wahrscheinlich KISS, aber das soll gut sein? Sorry, aber dann doch lieber komplexer und nicht solche Probleme.

142

OS-Design / Re: Nicht unterbrechbarer Kernel

« am: 11. October 2011, 17:35 »

Wieder der Kompromiss zwischen Performance (MAP_NOW) und Latenz (MAP_LAZY).

Nur das man das mit der Latenz ja lösen kann, nur ist es halt dann nicht mehr ganz so simpel (aber nicht viel komplexer, ist ja nur ne Schleife mehr, die man eh im UserSpace dann spätestens haben müsste).

143

OS-Design / Re: Nicht unterbrechbarer Kernel

« am: 11. October 2011, 16:28 »

Ich würde wetten das jeder von uns dieses "einfrieren" mehrmals pro Tag an seinem PC erlebt (egal ob da Windows oder Linux drauf läuft), diese Situationen sind nur normalerweise kurz genug das wir sie nicht bewusst wahrnehmen können.

Wenn diese Situationen kurz genug sind, dass man sie nicht wahrnimmt ist das ja in Ordnung, aber wenn der Sound schon aussetzt, dann ist das nicht mehr in Ordnung (ich rede hier von mehreren ms bis zu theoretisch Sekunden).

Wenn Du Dir bei der Speicherverwaltung auf Deinem 32 Bit-System, wo es nur um GBs und ein paar Hunderttausend Pages geht, schon solche Sorgen machst was denkst Du was uns auf fetten 64 Bit-System, wo es um TBs und ein paar Hundertmillionen Pages geht, erst erwartet?

Wenn man mal von meiner alten Mapping-Funktion absieht (meine aktuelle Funktion braucht keinen Lock), war meine Speichervaltung unterbrechbar.

Allerdings werde ich das mit dem Mapping dann auch so lösen, dass das in mehreren Schritten passieren wird (wie beim Allozieren der Pages).

ich habe doch auch nur vorgeschlagen dieses Problem in die libOS zu verlagern indem der Kernel zu große Speicheranforderungen mit MAP-Now ablehnt. Damit hast Du in der libOS 5 bis 10 Zeilen C-Code (also eine kleine Schleife die den Mapping-Syscall in mehreren Häppchen aufruft) mehr aber dafür keine Probleme im Kernel und das Interface zum normalen User-Code (z.B. mmap) bleibt trotzdem gleich.

Aber ob ich die Schleife nun im Kernel oder UserSpace habe ist doch erstmal egal, aber die Kontextwechsel sind verdammt teuer.

Um auch nochmal auf das MAP_NOW zurück zu kommen. Ist es nicht schon aus Effizienz-Sicht besser alles gleich zu mappen, als die teuren Exceptions das machen zu lassen?
Das wird doch nur zwecks Swapping und overcommitment gemacht (??).

Das viele andere OS das per Syscall machen liegt eventuell daran das diese nicht gut designt sind, oder? Vermutlich hat die anständige Planungsphase gefehlt.

Kommt drauf an was alles gemacht wird und welchen Zustand der Scheduler erwartet. Bei mir ging es nur darum, dass ich den IRQ direkt im Handler hatte und daher konnte ich den nicht nochmal dafür nutzen, aber eigentlich hätte ich das auch machen können. Nur war es bei mir einfacher, weil ich so ne Funktion (vorallem für die Kernel-Threads) hatte und nicht nen Int (was im Kernel eh über ne Funktion gelöst werden muss, da ich den Int ja erst zu Laufzeit kenne).

144

OS-Design / Re: Nicht unterbrechbarer Kernel

« am: 11. October 2011, 11:17 »

Sprich, wenn ein malloc() nicht am Stück, sondern mit zig Kontextwechseln zwischendurch stattfinden kann, beeinträchtigt das die Performance nicht, wenn aber erst bei Benutzung alloziiert wird, dann schon? Komische Milchmädchenrechnungen machst du da...

Also, erstmal reden wir besser nicht vom malloc(), sondern von vmmAlloc() (was im Kernel stattfindet, ansonsten könnte ein falscher Eindruck entstehen) und dann wäre bei meinem altem Design (und ich gehe mal von aus, bei jedem anderen Monolithen und nicht unterbrechbaren MikroKernel auch) genau das passiert. Es hätten theoretisch zig Kontextwechsel stattfinden können, entweder weil die Zeitscheibe abgelaufen ist oder weil ein IRQ gefeuert hat. Solange getade kein Lock gehalten wurde, war mein letztes Design unterbrechbar (und ne Lock wurde immer nur sehr kurz gehalten).
Sprich schlechter ist es nicht geworden und einen Kontextwechsel pro 4kb Page ist wesentlich mehr als max. ein Kontextwechsel pro 512 4kb Pages! Also ich finde das keine Milchmädchenrechnung.

Ich habe einfach im Hinterkopf, dass ich auf meinem Desktop unter Windows ein Treiberproblem habe und da sind die Ints einfach zu lange aus und deswegen habe ich Soundprobleme (knarksen und sowas). Das scheint immer nur aufzutreten, wenn auf die HDDs zugegriffen wird und manchmal auch wenn auf ein ODD zugegriffen wird.

Genau solche Probleme möchte ich vermeiden und deswegen will ich es auf gar keinen Fall das die Ints alzu lange aus sind.

Irgendwann werden wir mal Benchmarks mit deinem Betriebssystem machen und schauen, ob all deine Probleme wirklich relevant und gut gelöst sind.

Sehr gerne und ich weiß schon jetzt das es besser geht, ich es nur nicht besser weiß.

145

OS-Design / Re: Nicht unterbrechbarer Kernel

« am: 10. October 2011, 20:31 »

Das nennt man dann aber harte Echtzeitanforderungen... die willst du ja auch nicht.

Ich kenne jetzt nicht die genau Definition von harten Echtzeitanforderungen, aber so wie ich das interpretiere, haben die dann nicht alle OS? Weil es lässt sich bestimmt ne Obergenze finden, in der alle Aktionen fertig werden und das ist dann die Anforderung

Was willst du jetzt - höchsten Durchsatz oder geringste Latenz? Beides geht nicht. Definiere "Performance" und was du erreichen willst.

Ich würde gerne einen guten Kompromiss eingehen

Sprich wenn ich die Speicheranforderung unterbrechbar mache, dann kostet das im best-case unwesentlich mehr Zeit, aber der Zugriff auf den Speicher im Programm ist auf jeden Fall wesentlich schneller. Dabei muss ich dann halt den Kompromiss im Kernel eingehen.

Und am Ende des Tages möchtest du dann doch ein Array benutzen, weil es den Cache besser ausnutzt und daher im Normalfall doch schneller ist.

Kann durchaus passieren Kommt halt auf den Fall an.

Diese Locks kann sich eine normale Anwendung allerdings nicht holen, also auch nicht das System blockieren.

Diese Aussage verstehe ich nicht. Jede Anwendung kann bzw. muss doch in den Kernel und kann sich damit sehr wohl den Lock holen oder was meinst du?

Edit::

Ich habe mir nochmal meine Mapping-Funktion angeguckt und mind. nochmal der selbe Aufwand kommt fürs Mapping dazu. Also ist auch COW keine Lösung weil ja die Flags gesetzt und die TLB Einträge gelöscht werden müssen. MAP_LAZY wäre auch nicht viel besser, es müssen ja auch Flags gesetzt und die TLB Einträge gelöscht werden.

Dann kommt noch hinzu, dass ein Prozess entweder seinen Speicher nicht Stück für Stück freigibt oder beendet werden muss. Das Freigeben ist auch wieder teuer und kann unter Umständen richtig lange dauern. Selbst wenn die Anwendung nicht viel Speicher angefordert haben sollte, so nutzt sie vllt viele Libs und die müssen auch alle erstmal wieder geunmappt werden und wenn da dann ein paar 100MB zusammenkommen und überprüft werden muss ob der Speicher freigegeben werden kann oder ob er zum SharedMemory (z.B. Libs) gehört, könnte es schonmal passieren dass das gesamte System für eine Sekunde oder sogar länger hängt.

Ich denke das Problem ist nicht zu unterschätzen. Denn wie erik schon sagte, meine Rechnung ist naiv.

146

OS-Design / Re: Nicht unterbrechbarer Kernel

« am: 10. October 2011, 18:07 »

Um ehrlich zu sein denke ich das Du dieses Problem etwas überschätzt.

Kann gut sein, passiert mit oft.

Klar kann der PC mal für ein paar Millisekunden "einfrieren" wenn ein Task echt mal eine große Menge Speicher am Stück anfordert aber wie oft kommt das vor?

Das hat auf nem halbwegs modernen System nicht einmal vorzukommen, egal was für ne Situation es gibt!

Und noch ne andere Idee: was ist wenn Deine Kernel-API gar keine größeren Speicheranforderungen mit MAP-Now akzeptiert?

Ich kann jetzt nicht sagen, wie sehr die Performance einbrechen würde wenn bei z.B. einem 64mb Buffer, ab z.B. 4mb für jede Page eine Exception geworfen wird, aber das dürfte nicht zu verachten sein.
Warst du nicht eh ein Verfechter davon, dass das viel zu viel Zeit braucht und das man den Programmierer wählen lässt?

Zumal wieso ist hier die Methode, die Anwendung wie ein Baby zu behandeln gut?

Ich hab echt den Eindruck das Du Dir immer die maximal umständlichsten Lösungen ausdenkst.

Auch das ist eine Lösung. Ich versuche halt oft nicht die Bedingungen zu ändern (bei deinem Bsp. Map-Lazy ab einer bestimmten Speichermenge), sondern den Weg.

Willst Du ernsthaft die Thread-Art zur Laufzeit ändern?

Du stellst dir das komplexer vor als es ist. Ich würde einfach nur nen neuen Stack allozieren und den als per CPU-Stack eintragen und den aktuellen Stack in der Thread-Struktur speichern. Mehr wäre das nicht und da meine Kernel-Stacks 4kb groß sind, ist das auch nicht Zeitaufwendig.
Wenn man dann noch ein wenig Caching betreibt, dass man z.B. die Stacks danach nicht freigibt, sondern in eine Liste packt, ist nur das erste Mal "teuer".

Ich kann nur wiederholen das Simplizität ein essentiell wichtiges Design-Paradigma ist.

Darüber lässt sich jetzt streiten. Es kommt halt drauf an was man erreichen will. Ne Liste ist immer einfacher als z.B. nen Baum und trotzdem wirst du bei den entsprechenden Fällen nen Baum wählen. Ist das dann deswegen ein schlechtes Design?

von daher sehe ich da kein Sicherheitsrisiko wenn man gezielt den INT-Vector freigibt auf den der Timer-IRQ gemappt ist (solange dieser IRQ nicht geshared ist).

Das stimmt, dann müsste ich das nur in meiner libos einbauen, weil der Timer-IRQ ja nicht immer auf den selben Int gemappt ist (PIT und lokaler-APIC). Da muss ich nochmal genauer drüber nachdenken. Wieso haben das andere OS nicht? Soweit ich weiß ist yield() immer ein Syscall.

147

OS-Design / Re: Nicht unterbrechbarer Kernel

« am: 10. October 2011, 15:37 »

Willst du harte Echtzeitbedingungen erfüllen oder nicht? Und wenn ja, in welcher Größenordnung?

Nein will ich nicht, aber es wäre mehr als nur unschön, wenn das System gerade hängt nur weil Speicher angefordert wird.

Darum macht man ja auch Copy on Write... dann verteilt sich das Problem von "ich will jetzt aber ganz viel RAM" in eine Reihe von Pagefaults.

Ich glaube das hatten wir schonmal und es lief darauf hinaus, dass das Programm es am besten wissen sollte und man es nicht im OS so festschreiben sollte bzw. halt normal COW und wenn das Programm besondere Wünsche hat, dann muss es das angeben.

Du kennst dich ja auch ein wenig mit Linux aus, wie war das eigentlich damals mit dem Big-Kernel-Lock, theoretisch würde man ja die Ints ausmachen, aber bei nem Monolithen geht das nicht, also konnte es passieren, dass ein Thread der den Lock hält alle andere die in den Kernel wollten blockiert oder? Dann sollte das doch am besten als Mutex implementiert gewesen sein?!
Denn dort könnte ja rein theoretisch das selbe Problem bestehen.

148

OS-Design / Re: Nicht unterbrechbarer Kernel

« am: 10. October 2011, 10:43 »

Mir fällt kein sinnvoller Einsatzzweck für deinen geschilderten Fall ein.

Naja, wie erik schon richtig erkannt hatte, habe ich mich bei der Anzahl der Pages schonmal vermacht, aber das ein Programm, meinetwegen 64MB Speicher haben will und dann der PC für die gesamt Zeitspanne blockiert ist (da ja auch keine IRQs mehr angenommen werden) und das vielleicht noch von einem Task mit niedriger Priorität, kann doch schonmal vorkommen.
Und selbst bei 64MB reden wir hier von mehreren ms (schon bei meiner naiven Rechnung) und ich denke das macht sich sehr wohl für den User bemerkbar.

Du kennst Deine Fehler ganz genau und machst diese trotzdem. Mal so unter uns zwei, ist das Deiner Meinung nach intelligentes verhalten?

Nennen wir es faules Verhalten

Ich bin halt spontan und merke dann später erst was ich mir da aufgehalst habe.

Das sind aber schon 4 GB Speicher und nicht bloß 1 GB!

Wenigstens einer der aufpasst Jap, aber auch mit 1GB wird es nicht schöner.

Das ist nicht großzügig sondern naiv, vor allem weil ja einige Speicherzugriffe dabei sind.

Ich weiß, ich wollte auch nur zeigen, dass man sich das nicht mal schön rechnen kann.

Dann kannst du auch gleich direkt den Scheduler aufrufen. Prinzipiell eine interessante Idee aber wenn man eine zeitaufwendige Aktion ausführt dann dauert die eben etwas, dort auch noch ständig zu unterbrechen kostet unterm Strich nur noch mehr Zeit (Cache-Trashing usw.), ich persönlich halte davon nix.

Da ich gestern eh nicht richtig schlafen konnte, habe ich mir darüber nochmal ein paar Gedanken gemacht.

Meine Idee dafür ist, da ich eh Kernel-Threads haben will, brauche ich auch die Möglichkeit zw. Kernel-Threads und User-Threads zu unterscheiden (Kernel-Threads haben ihren eigenen Stack und User-Threads benutzen den per CPU Kernel-Stack) und beim Allozieren und Deallozieren lege ich ein Anzahl von Schleifendurchläufen fest (vllt 512) und wenn mehr als 512 4kb Pages benötigt werden, wird der Thread zu einem Kernel-Thread und bekommt seinen eigenen Stack. Es werden dann die 512 Schleifendurchläufe gemacht (wobei eine 4mb Page als nur ein Schleifendurchlauf zählt) und danach werden die Ints angemacht und es wird "pause" ausgeführt. Damit hat die CPU zeit, eventuell gequeuete IRQs abzuarbeiten.
Die Ints werden dann wieder ausgemacht und es werden bis zu weitere 512 durchläufe gemacht.

Das sollte Performancemäßig ein guter Kompromiss sein und ich sollte damit die meisten Speicheranforderungen ohne extra Kernel-Stack ausführen können.

Warum geht der Thread zum Abgeben der Zeitscheibe per Syscall in den Kernel? Der kann doch auch INT 0x?? benutzen (0x?? durch den IRQ-Vector des Timer-IRQs ersetzen).

Hmm, den Fall habe ich noch gar nicht betrachtet, weil das auch nen potentieller Angriffspunkt ist. Denn ein Programm könnte dann ja munter einfach irgendwelche IRQs auslösen und das wäre ja sehr unschön.
Konnte man das nicht irgendwie begrenzen welche Ints aus dem UserSpace aufgerufen werden können?

Zumal direkt den IRQ des Timer´s aufzurufen auch unschön wäre, weil ich so nicht einfach feststellen kann, ob nun der Timer oder der User den IRQ ausgelöst haben (gut da ich eh immer den Timer-Counter auslöse kann ich das).

Und dieser Zeitscheibe-Abgelaufen-IRQ (falls es den einer ist) schmeißt den frischen Thread auch gleich wieder von der CPU runter.

Nope, das fange ich ganz geschickt ab, entweder es ist wirklich mit einmal ein Thread verfügbar der ne höhere Priorität hat oder aber der Thread wird weiter ausgeführt da seine Zeitscheibe ja noch nicht aufgebraucht ist.

oder Du baust etwas ein das der Scheduler am Ende prüft ob der Zeitscheiben-Timer gerade einen IRQ auslösen möchte und quittiert das einfach so das wenn dann die CPU die INTs wieder enabled eben kein Timer-IRQ mehr ansteht. Bei Level-Triggered-IRQs gibt es ja nichts persistentes im IRQ-Controller, bei Edge-Triggered-IRQs hast Du da schon eher ein Problem.

Ich wüsste nicht wie ich das so ohne weiteres feststellen sollte, ob der Timer noch nen IRQ ausgelöst hat (während ich den Counter lese und wieder neu schreibe) und ein fach per gut Glück nen EOI zu senden ist auch keine gute Idee, dann kann es ja passieren, das ich vllt den falschen IRQ "wegwerfe" (was so oder so ein Problem ist).

Was ist mit meiner Idee, dass ich mir immer merke wie ich in den Kernel gekommen bin (also ob es nen Syscall oder nen IRQ war) und dann bei nem IRQ nen EOI sende, aber immer mit der optimalen Methode aus dem Kernel gehe (also nicht iret, sondern Sysret/Sysexit)? Das sollte doch eigentlich keine Probleme geben?

149

OS-Design / Nicht unterbrechbarer Kernel

« am: 09. October 2011, 23:35 »

Jetzt habe ich mich gerade damit angefreundet (und angefangen entsprechenden Code zu schreiben) das ich einen nicht unterbrechbaren MikroKernel schreibe und schon fallen mir die ersten Probleme auf (Designphase mal wieder übersprungen -> erik ).

Also erstmal sollte man sich darüber im Klaren sein, das es auf x86 keinen 100%ig nicht unterbrechbaren Kernel gibt. Zumindest nicht wenn man nicht auf "hlt" oder andere Stromsparmechanismen verzichten möchte.

Ein anderes Problem ist mir erst jetzt bewusst geworden. Die Zeit die im Kernel verbracht wird, kann schonmal verdammt lange werden, nämlich dann wenn der User Speicher haben möchte.
Stellen wir uns einfach vor, wir sind auf einem Single-Core System (funktioniert auch auf nem Dual-Core System, wo alle CPUs gleichzeitig in den Kernel gehen und Speicher wollen, desto mehr CPUs desto unwahrscheinlicher wird es) und der User will z.B. 1GB Speicher haben.
Das Nachgucken und Besorgen eines Bereiches vom UserSpace der groß genug ist, sollte relativ schnell gehen (kann also vernachlässigt werden), aber das Besorgen der nötigen Pages ist ein Teil des Problems. Wir reden also von 1048576 4kb Pages und weil es mir um den worst-case geht, kann ich auch keine 4mb Pages nehmen. Da für jede Page der PMM aufgerufen werden muss und dieser mit einem Lock geschützt ist, rechnen wir mal so über den Daum gepeilt mit 20 Instruktionen (das ist schon wenig) pro Page, macht schonmal 20971520 Instruktionen und ich bin großzügig und rechne mal mit nur 2 Takten pro Instruktion, macht 41943040 Takte.

Jetzt gehe ich mal von 100MHz aus, ein Takt entspricht also 10ns und für obige Takte entspricht das dann 419430400ns was 419,4304ms macht und das nur um die Pages zu holen, da sind die noch nicht mal gemappt. Auch bei 1000MHz wird es nicht besser mit 41,94304ms, die dafür gebraucht werden.

Wie soll man sowas also lösen?

Ja man könnte für sowas (bzw. ist es der einzige Fall der mir einfällt, der so lange dauern könnte und natürlich der entgegengesetzte Fall, das Freigeben) Punkte einrichten, wo der Kernel dann unterbrechbar ist, aber wo würde man diese Punkte hinpacken? Weil ich will den Kernel dann z.B. nicht bei 4 Pages unterbrechen.

Ein weiteres Problem (was relativ einfach zu lösen ist) ist, dass ein Thread ja seine Zeitscheibe abgeben kann und dazu geht er per Syscall in den Kernel. Dort wird dann der Scheduler aufgerufen und der wählt einen neuen Thread aus. Problem ist hier nun, das der Scheduler immer aus dem Kernel springt, als wenn es ein IRQ wäre, aber in diesem Fall darf kein EOI gesendet werden. Das lässt sich lösen, dass man einfach jedes Mal wenn man in den Kernel springt, ein Flag setzt ob der Grund ein IRQ war oder nicht, aber das müsste man auch noch für jeden Thread speichern (wie er in den Kernel gekommen ist). Denn wenn der Thread per Syscall reingekommen ist, will man natürlich auch wieder auf dem Weg heraus (Sysret oder Sysexit).

Kleine Idee am Rande, ist es möglich, wenn ich weiß das der Thread zurück in den UserSpace geht, dass ich jedes Mal mit Sysret/Sysexit aus dem Kernel gehe (ich kann ja vorher nen EOI senden und das Page Directory wechseln, sowie andere nötige Sachen machen)? Damit könnte ich sogar ISRs ein wenig beschleunigen. Denn die sollten schneller sein als ein iret.

Auch müssen jedes Mal die Register, die beim Eintritt in den Kernel auf dem per CPU Kernel-Stack gespeichert werden, in der Thread-Struktur gespeichert werden, was auch nochmal ein paar Takte kostet.

Ein anderes Problem, welches aber auch für einen unterbrechbaren Kernel zutrifft, ist halt das Abgeben der Zeitscheibe. Denn dazu wird in den Kernel gesprungen und der Scheduler wird aufgerufen, dort (im Scheduler) müssen die Ints aus sein und genau in der Zeit kann es passieren das der Timer-IRQ feuert und dann gequeuet wird. Es wird ein neuer Thread ausgesucht und der Scheduler springt zurück in den UserSpace und was wird als erstes gemacht? Es wird wieder in den KernelSpace gesprungen, weil ja der IRQ abgearbeitet werden muss.

Kann man dagegen irgendetwas machen oder muss man damit leben? Auch das Abschalten oder maskieren hilft ja nicht, weil ja Zeit bis dahin vergeht wo ja ein IRQ auftreten kann.

150

OS-Design / Re: GUI LowLevel

« am: 09. October 2011, 18:39 »

Andere Architekturen z.B. ARM kennen doch auch DMA (und sogar in der veralteten, es muss physisch zusammenhängender Speicher sein, Variante). Wie sicher ist das denn dort?
Dort kann doch bestimmt auch der Shader-Code dann auf den gesamte RAM zugreifen oder? Bzw. kann man dort nicht z.B. auch steuern wieviel RAM z.B. die Graka bekommt? Dann könnte man also auch ganz leicht diesen Bereich verändern.

151

OS-Design / Re: GUI LowLevel

« am: 09. October 2011, 13:01 »

Auch wenn´s total OT ist, aber das mit dem Bundestrojaner ist im Mom viel interessanter, vorallem da wir uns da auf das verlassen was einige wenige sagen, die auch auch verarscht worden sein können.

152

OS-Design / Re: EOI, wann senden?

« am: 09. October 2011, 09:35 »

Hm, gibt es bei den APICs wirklich keinen Mechanismus mit dem man einen IRQ per Default erst mal maskieren kann? Du hattest doch was von einem "IRR-Bit" geschrieben, kann man damit nicht irgendwas drehen? Ich kenne die APICs nicht wirklich und hab auch nie die Spezifikation komplett durchgelesen, daher kann ich Dir da leider nicht wirklich helfen, sorry.

Bitte ganz genau sagen, welchen APIC du meinst, ob Lokalen oder IO! Denn was nutzt es dir wenn der IRQ im Lokalen-APIC maskiert ist, deswegen können die anderen CPUs den gleichen IRQ trotzdem empfangen.

Soweit ich es verstanden habe, ist der IRQ aber im IO-APIC nur bis zur Empfangsbestätigung maskiert:

The IOAPIC responds to an edge triggered interrupt as long as the interrupt is wider than one CLK cycle. The
interrupt input is asynchronous; thus, setup and hold times need to be guaranteed for at lease one rising edge of
the CLK input.  Once the interrupt is detected, a delivery status bit internal to the IOAPIC is set. A new edge on
that Interrupt input pin will not be recongnized until the IOAPIC Unit broadcasts the corresponding message over
the APIC bus and the message has been accepted by the destination(s) specified in the destination field. That
new edge only results in a new invocation of the handler if its acceptance by the destination APIC causes the
Interrupt Request Register bit to go from 0 to 1. (In other words, if the interrupt wasn't already pending at the
destination.)

Vielleicht habe ich den Abschnitt aber auch falsch verstanden.

In dieser Zeit werden zwar weitere IRQ-Signale von dem zugehörigen HW-Gerät für den betreffenden IRQ angenommen (und auch ordnungsgemäß gezählt) aber eben nicht an eine CPU ausgeliefert.

Könnte der Counter nicht theoretisch dann irgendwann überlaufen? Allerdings glaube ich dass das Gerät vorher die Daten wegwirft, bevor sowas passiert.

153

OS-Design / Re: GUI LowLevel

« am: 09. October 2011, 09:28 »

Solange Shadercode ungeprüft in die Grafikkarte gespielt wird stellt dieser auch immer ein Sicherheitsrisiko dar, egal welche Anwendung den einschleppt.

Wird der Code denn vom Treiber überprüft und selbst wenn, auch die (Treiberprogrammierer) machen Fehler?

Was mich daran nur gerade wundert, wieso habe ich davon noch nie was gehört? Ich meine das ist doch schon nen potentielles Risiko, vorallem wenn man dann an WebGL denkt.

154

OS-Design / Re: GUI LowLevel

« am: 08. October 2011, 22:23 »

Ich wusste nicht das man mit Hilfe von Shadercode soviel (auf jeglichen Speicher zugreifen) machen kann. Ist dass dann aber nicht immer ein Problem (auch bei normalen Anwendungen)?

155

OS-Design / Re: GUI LowLevel

« am: 08. October 2011, 22:04 »

und zum thema gui: die grafikkarte ist da keine ausnahme. opengl im browser hardwarebeschleunigt heißt, webseitencode hat vollzugriff auf physischen speicher (falls keine iommu aktiv).

Aber nur auf vom GUI "genehmigten" RAM oder?

156

OS-Design / Re: GUI LowLevel

« am: 08. October 2011, 21:45 »

Was ist eigentlich mit so sachen, das es möglich ist von außen fremden Code einzuschleußen, passt das da noch rein? Ich meine damit nicht mal unbedingt Buffer-Overflows oder sowas, sondern, war es nicht sogar Firewire (oder Thunderbolt??), dass einem Gerät zuviel Möglichkeiten (hardwaretechnisch) gegeben wurden, so dass Code ohne Eingriff der Software eingeschleust werden kann.

157

OS-Design / Re: GUI LowLevel

« am: 08. October 2011, 20:21 »

Eigentlich lehne ich ja die Existenz von Chaos grundsätzlich ab

Ich wollte mit der Chaostheorie auch nur darauf hinaus, des ich dem Menschen die Fähigkeit abspreche, ein so komplexes System wie die Natur 100%ig genau vorraus zu sagen. Dazu gibt es einfach zu viele Faktoren und alleine schon das Erfassen/Messen aller Faktoren (im Endeffekt müsste man ne komplette Momentaufnahme des gesamten Systems, sprich des gesamten Universums machen, um alle Faktoren zu kennen) ist einfach unmöglich. Weil ja jeder Faktor rein theoretisch einen Einfluss haben könnte, der das Ergebnis verändert (die meisten Wirkungen dürften sich selbst unserer Vorstellungskraft entziehen).

Und ein System als abgeschlossen zu betrachten, ist auch nur ein Hilfskonstrukt um externe Einflüsse ausschließen zu können und damit Sachen einfacher zu machen.

158

OS-Design / Re: EOI, wann senden?

« am: 08. October 2011, 20:16 »

Selbst bei Edge-Triggered-IRQs sollte es nicht passieren das der selbe IRQ an einen anderen IRQ-Controller geschickt wird.

Soweit ich es verstanden habe, ist der edge-triggered IRQ mit der Annahme (dem ACK) am Lokalen-APIC abgeschlossen und es kann ein neuer IRQ verarbeitet (im IO-APIC) werden. Dieser neue IRQ kann ja wieder ein edge-triggered IRQ (vom selben Gerät) sein und ein andere Prozessor hat jetzt ne niedrigere Priorität als der der den letzten IRQ immernoch bearbeitet.
Dann kommt es zur Situation das der Handler wieder aufgerufen wird, obwohl gerade eine andere CPU im gleichen Handler ist.

Das könnte z.B. das maskieren des IRQ im ersten IRQ-Controller (der diesen IRQ entgegen nimmt) sein oder z.B. ein automatisches Maskenregister im HW-Gerät

Problem, wie oben erläutert, ist die Zeit bis zum Maskieren des IRQ und ich will mich ehrlich gesagt nicht abhängig machen von irgendeinem Treiber. Ja, man kann die CPU und damit den PC damit in die Knie zwingen, aber es sollte zu keinem Problem kommen, nur weil der Handler auf mehreren CPUs gleichzeitig läuft (was eine Form der Synchronisierung erfordert).

Wenn Du wirklich Edge-Triggered-IRQs sinnvoll einsetzen möchtest (was MSI(-X) zwingend voraussetzt) dann solltest Du aber darüber nachdenken den HW-Geräten, bei denen mit hohem IRQ-Aufkommen zu rechnen ist, mehrere IRQs zuzuweisen um somit die IRQ-Last bequem auf mehrere IRQs und mehrere CPUs verteilen zu können.

Kann das der PCI-Bustreiber ermitteln oder muss ich mich da auf den Treiber verlassen, der halt mehrere IRQs anfordert?

Zwecks "focus processor" zitiere ich mal das Intel Manual:

(P6 family and Pentium processors.) For these processors, if a focus processor
exists, it may accept the interrupt, regardless of its priority. A processor is said to be
the focus of an interrupt if it is currently servicing that interrupt or if it has a pending
request for that interrupt. For Intel Xeon processors, the concept of a focus processor
is not supported.

Heißt im Endeffekt, wenn eine CPU schon den gleichen IRQ bearbeitet, wird auch der gerade eingetroffene IRQ (trotz anderer Prioritäten) wieder an diese CPU geleitet.

159

OS-Design / Re: GUI LowLevel

« am: 08. October 2011, 19:17 »

Und solange man annimmt, dass die Hardware funktioniert, ist sie ebenfalls streng deterministisch... von defekter Hardware gehen wir hier ja nicht gerade aus.

Ich will damit auch nur sagen, dass es die Dinge sind, die man nicht einplant bzw. einplanen kann, die alle so schön deterministisch sind, die einem dann in der Praxis nen Strich durch die Rechnung machen.

Ja, die kann man mit Statistik erschlagen.

Jap, aber halt nicht zu 100%.

160

OS-Design / Re: GUI LowLevel

« am: 08. October 2011, 19:06 »

Software ist immer ein hermetisch abgeschlossenes und streng deterministisches System! Gibt es da etwa gegenteilige Meinungen?

Naja, die Hardware auf der die Software läuft ist das Problem.

Aber für die meisten technischen Systeme sollte es möglich sein deren Wirkmechanismen vollständig zu verstehen, selbst bei chaotischen Systemen kann man in gewissen Grenzen mit Häufigkeiten u.ä. rechnen.

Schonmal was von der Chaostheorie gehört?

Es gibt so viele Faktoren, gerade bei technischen Systemen, die man einfach nicht voraussehen kann, noch kennt man heute alle.

Was mir noch zwecks Theorie einfällt, ist Physik, da wird soviel weggedacht, damit es sich einfacher rechnet, aber 100%ig genau ist es deswegen nicht. Ich kenne einen Fall wo ein nicht studierter eine Anlage besser bedienen konnte (zwecks Erfahrung aus der Praxis und durch Beobachtung) als ein Ingeneur.

Jetzt aber genug OT