Thema: IPC - Popup-Threads

[FlashBurn]

Also der Kernel-Heap muss nicht nur in der Lage sein Objekte zu liefern sondern auch ganze virtuelle Pages (ohne gleich zwangsläufig physischen Speicher dahinter zu legen, sondern nur optional). Diese Fähigkeit muss er doch eigentlich sowieso haben da er ja auch ganze Pages benutzen muss um daraus SLAB-Blöcke zu bauen (und was anderes als ganze Pages können auch nicht mit Hilfe des PMM mit echtem physischen Speicher hinterlegt werden). Dann musst Du diese interne Fähigkeit des Kernel-Heap als zusätzliches Interface verfügbar machen. Der Kernel-Heap muss doch eh intern einen Baum pflegen um den virtuellen Kernel-Speicher zu managen (so wie der Prozess-VMM den virtuellen Speicher der Prozesse managed, nur mit dem Unterschied das der Prozess-VMM für seine Baum-Objekte einfach den Kernel-Heap benutzt und der Kernel-Heap dafür sich selbst benutzen muss).

Und das empfindest du nicht als Hack? Weil ich ja immer den jeweiligen Allocator um eine Funktionalität erweitern muss, die er normalerweise nicht erfüllen muss.

Also für mich hat der SlabAllocator nix mit der Verwaltung virtueller Adressen zu tun, das ist gar nicht seine Aufgabe. Anders gefragt, wieso findest du eine Ebene mehr beim User ok und beim Kernel nicht? Mit der Ebene mehr meine ich das was ich unter einem VMM verstehe, sprich das Verwalten virtueller Adressen/Pages.

Warum soll das bei meinem Vorschlag nicht gehen? Solange man jeder Ebene ein sauberes Interface verpasst und die anderen Ebenen dieses Interface korrekt benutzen kann man auch jede Ebene individuell beliebig austauschen.

Wenn ich die Verwaltung für die virtuellen Adressen ändern möchte, müsste ich bei deiner Idee am SlabAllocator rumspielen bzw. wenn ich den SlabAllocator gegen was anderes austauschen möchte, muss ich auch den neuen Allocator dahingehend anpassen, dass er diese Verwaltung mit beinhaltet. Das ist für mich halt weder sauber getrennt noch einfacher.

Du baust zw. beiden eine zu große Abhängigkeit voneinander auf. Um nochmal mein Bsp zu bringen. Bei deiner Variante ist es nicht einfach möglich den Allocator auszutauschen, bei meiner schon.

Ich bin, was deine Idee betrifft, auch leider schon negativ vorbelastet. Ich hatte, wie gesagt, vorher den SlabAllocator für die Objekte des VMMs mit genutzt und das gab nur Probleme und war ein einziger Hack. Alleine schon deswegen, weil ich von außerhalb des SlabAllocators Pages für bestimmte Objekte "injezieren" musste.

Im Endeffekt geht es ja darum, dass ich um Speicher in einem anderen Prozess zu allozieren, dass PD wechseln muss. Davon ausgehend dass das eigentlich nur der Fall ist wenn ich sowieso an einen Thread in dem anderen Prozess abgebe (mir fällt gerade kein wirklicher Fall ein, wo das nicht so ist, es gibt ihn aber bestimmt), dürfte das doch nicht so das Problem sein oder?

Ich weiß ich reite immer gerne auf dem worst-case rum, aber der kommt manchmal schneller als man denkt. Mir gefällt an der Variante das die User-VMMs alle den SlabAllocator nutzen nicht, dass im worst-case eine riesige Speicherverschwendung auftritt. Mir ist auch klar dass das gleiche Problem auch bei meiner Variante (jeder User-VMM nutzt praktisch seinen eigenen SlabAllocator) auftritt, aber halt in wesentlich kleiner Ausführung. Dem könnte man entgegnen dass bei deiner Variante der verschwendete Speicher wieder von anderen User-VMMs genutzt werden kann und bei meiner nicht.

Auf der anderen Seite, ich kann es zu gegebener Zeit auch einfach mal Testen, dazu muss ich genau einen Konstrukturaufruf ändern (2 Werte) und es wird der allgemeine SlabAllocator dafür genutzt.

[erik.vikinger]

Hallo,

Und das empfindest du nicht als Hack?

Eigentlich nicht, nö.
Das Problem ist das der Slab-Allocator ganze Pages braucht (z.B. von einem VMM) aber zur Verwaltung dieser Pages (im virtuellen Adressraum) benötigt man wieder passende Verwaltungsstrukturen (z.B. einen Baum) und dafür bietet sich wieder der Slab-Allocator an (ist ja auch seine Spezialität). Daraus ergibt sich dann ganz schnell eine eklige Kreisabhängigkeit die auch wieder blöde Probleme erzeugen kann, aus diesem Grund betrachte ich es nicht als Hack das beides zu einem Stück zusammen zu fassen.
In meinem OS möchte ich aber genau diese beiden Dinge voneinander trennen und muss dafür mit der Kreisabhängigkeit klar kommen (ich denke das wird mir auch gelingen), Svenska würde gerade das einen ekligen Hack nennen.
Aus meiner Sicht ist beides Okay, man muss es nur ordentlich umsetzen. Einen einfachen Königsweg der dieses Problem komplett vermeidet (und auch keine sonstigen Nachteile bringt) gibt es wohl nicht, ich kenne zumindest keinen.

Das ist für mich halt weder sauber getrennt noch einfacher.

Wenn Du das trennen möchtest dann nur zu aber dann musst Du auch mit der Kreisabhängigkeit klar kommen, oder wo her soll sich der Kernel-VMM (unter dem Kernel-Heap-Slab-Allocator) seine Verwaltungsstrukturen holen?

Im Endeffekt geht es ja darum, dass ich um Speicher in einem anderen Prozess zu allozieren, dass PD wechseln muss. Davon ausgehend dass das eigentlich nur der Fall ist wenn ich sowieso an einen Thread in dem anderen Prozess abgebe (mir fällt gerade kein wirklicher Fall ein, wo das nicht so ist, es gibt ihn aber bestimmt), dürfte das doch nicht so das Problem sein oder?

So aus dem leeren Bauch heraus kann ich auch nicht abschätzen wie viele Situationen es gibt das man aus dem Kontext des einen Prozess am Speichermanagement eines anderen Prozesses drehen muss aber ich könnte mir vorstellen das da vielleicht Dinge wie Memory-Sharing oder gar Memory-Mapped-Files (wo das VFS im Adressraum anderer Prozesse rumhantieren muss, das geht mit meinen Segmenten auf jeden Fall einfacher zu lösen) gewisse Anforderungen stellen. Ich schätze daher das es für die Zukunft nicht schadet wenn sowas gut funktioniert.

Ich weiß ich reite immer gerne auf dem worst-case rum

Kein Problem, an den muss gedacht werden. Ich denke unsere zwei Varianten unterschieden sich vom Speicherverbrauch nicht viel (und von der Performance sicher auch nicht), es wird nur in verschiedenen Abschnitten des virtuellen Adressraum gebucht. Klar könnte das in einem Kernel mit nur einem einzigen GB an virtuellem Adressraum eher knapp werden als wenn das alles Prozess-lokal läuft aber ich denke so kritisch ist das nicht und wenn doch ist es vielleicht ein guter Grund auf 64Bit umzusteigen.


Grüße
Erik

[FlashBurn]

Wenn Du das trennen möchtest dann nur zu aber dann musst Du auch mit der Kreisabhängigkeit klar kommen, oder wo her soll sich der Kernel-VMM (unter dem Kernel-Heap-Slab-Allocator) seine Verwaltungsstrukturen holen?

Naja, es klingt wahrscheinlich wieder blöd weil es von mir kommt, aber dazu habe ich noch nen Allocator geschrieben Der ist aber einfacher und vorallem statisch. Ich lege zur Compilezeit nen Bereich fest und den verwaltet er und dazu braucht er keinerlei dynamischen Speicher. Der zusätzliche Verbauch liegt bei 8-16byte pro benötigter Page.

Ich denke unsere zwei Varianten unterschieden sich vom Speicherverbrauch nicht viel (und von der Performance sicher auch nicht), es wird nur in verschiedenen Abschnitten des virtuellen Adressraum gebucht.

Sie skalieren nur anders. Meine Variante hat als einzigen Engpass den Prozess und deine den allgemeinen Kernel-Allocator.

Was mir gerade noch klar geworden ist, auch bei deiner Variante müsste ich das PD wechseln oder zumindest in Teilen in den Kernel mappen, da ich ja auch Speicher in die PageTables eintragen muss. Von daher finde ich einen extra VMM schon besser und auch das Wechseln des PDs sollte einfacher sein, als Teile zu mappen und sich nur mehr Komplexität einzuhandeln.

Klar könnte das in einem Kernel mit nur einem einzigen GB an virtuellem Adressraum eher knapp werden als wenn das alles Prozess-lokal läuft aber ich denke so kritisch ist das nicht und wenn doch ist es vielleicht ein guter Grund auf 64Bit umzusteigen.

Auf 64bit möchte ich fürs erste verzichten, wenn ich denn irgendwann mal soweit bin, dass ne Konsole läuft und ich ein paar Treiber habe, kann ich mir darüber Gedanken machen. Bis dahin werde ich noch auf viele Probleme stoßen und diese ganzen Erfahrungen helfen dann dabei für ein 64bit OS "bessere" Entscheidungen zu treffen.

[erik.vikinger]

Hallo,

Naja, es klingt wahrscheinlich wieder blöd weil es von mir kommt, aber dazu habe ich noch nen Allocator geschrieben Der ist aber einfacher und vorallem statisch. Ich lege zur Compilezeit nen Bereich fest und den verwaltet er und dazu braucht er keinerlei dynamischen Speicher. Der zusätzliche Verbauch liegt bei 8-16byte pro benötigter Page.

Nunja, also gerade elegant oder effizient klingt das tatsächlich nicht (und das nicht nur weil es von Dir kommt). Wenn Dein Kernel 1 GB, also 262'144 Pages, belegt dann macht das 2 MB bis 4 MB statischen Verbrauch für Deinen Mini-Allocator. Mir persönlich wäre das zu viel. Vor allem ist es IMHO doppelter Unsinn weil Du doch schon einen tollen SLAB-Allocator hast.

Sie skalieren nur anders.

Das ist richtig, aber beim SLAB-Allocator kann man da ja mit dem CPU-lokalen Magazin-Mechanismus entgegen wirken.

Was mir gerade noch klar geworden ist, auch bei deiner Variante müsste ich das PD wechseln oder zumindest in Teilen in den Kernel mappen, da ich ja auch Speicher in die PageTables eintragen muss.

Deswegen hatte ich ja auch eigentlich Vorgeschlagen das alle PDs immer im virtuellen Adressraum des Kernels sichtbar sind, das bringt IMHO maximale Flexibilität und geringste Komplexität.
Wenn ich Dich richtig verstanden habe willst Du doch das oberste GB des virtuellen Adressraums dem Kernel geben, das zweitoberste GB ist dann Prozess-lokal aber trotzdem nur für den Kernel zugänglich und der Prozess bekommt dann die unteren 2 GB. Dann gib doch dem Kernel gleich die ganzen oberen 2 GB und schon ist Dein Problem weitestgehend gelöst. Und wie viel Speicher der Kernel-VMM vom Kernel-Heap zur Verwaltung der 2 GB virtuellen Kernel-Adressraums benötigt hängt dann im wesentlichen davon ab wie gut Du die Fragmentierung in den Griff bekommst und das sollte sich doch innerhalb des Kernel einigermaßen gut lösen lassen (zumindest sollten da keine 2 bis 4 MB drauf gehen).

und diese ganzen Erfahrungen helfen dann dabei für ein 64bit OS "bessere" Entscheidungen zu treffen.

Bei einem 64Bit-OS trifft man ganz andere Entscheidungen. Dort wird man z.B. immer den gesamten physischen Speicher (mitsamt aller HW-Geräte) in den virtuellen Kernel-Adressraum 1:1 einblenden, einfach weil es bequem machbar ist und ne Menge grauer Haare erspart.


Was ich mich noch frage ist warum Du überhaupt so wesentliche Teile Deines Kernels wie die Speicherverwaltung austauschbar haben willst. Die Speicherverwaltung ist IMHO eine der wichtigsten Komponenten in einem OS-Kernel (bei einem Micro-Kernel sicher auch eine der größten, was Code-Umfang usw. angeht), der Kernel wird sich an vielen Stellen auch implizit auf ein bestimmtes Verhalten der Speicherverwaltung verlassen so das ein Austauschen wahrscheinlich trotz klarer API gar nicht so einfach ist wie Du jetzt vielleicht denkst. In meinem Design betrachte ich den Micro-Kernel als relativ monolithische Einheit, klar werden da ein paar Dinge (wie z.B. der Treiber für den IRQ-Controller oder den HW-Timer) auf Quell-Code-Ebene recht modular und austauschbar sein aber die wesentlichen Kernelemente sind aus einem Guss. Eine andere Herangehensweise macht IMHO auch keinen echten Sinn. Soweit wie beim L4, wo man sagt das (fast) jede Architektur-Variante ihren eigenen speziell angepassten Kernel bekommt, muss man ja auch nicht unbedingt gehen aber das Gegenteil davon, was Du wohl momentan versuchst zu erreichen, ist IMHO ebenfalls nicht sehr zielführend.


Grüße
Erik

[FlashBurn]

Wenn Dein Kernel 1 GB, also 262'144 Pages, belegt dann macht das 2 MB bis 4 MB statischen Verbrauch für Deinen Mini-Allocator. Mir persönlich wäre das zu viel.

Da habe ich dann mal wieder zu wenig Infos preisgegeben. Mit statisch meinte ich eigentlich die größe des Bereichs, es werden auch dort Pages so wie sie gebraucht werden reingemappt, aber ich muss nicht Buch führen wie groß der freie Bereich ist oder ob noch genug frei ist, weil der Bereich der verwaltet wird groß genug für den worst-case ist (plus ein wenig mehr, um ein vernünftiges Alignment zu bekommen).

Dieser Allocator ist ein sehr vereinfachter SlabAllocator, halt nur ohne die große dynamische Verwaltung. Im Endeffekt könnte man sagen, dass ist das was du mir die ganze Zeit vorschlägst nur für nen ganz kleinen statisch festgelegten Bereich.

Wenn ich Dich richtig verstanden habe willst Du doch das oberste GB des virtuellen Adressraums dem Kernel geben, das zweitoberste GB ist dann Prozess-lokal aber trotzdem nur für den Kernel zugänglich und der Prozess bekommt dann die unteren 2 GB.

Jetzt könnte ich auch schreiben, dass du mich einfach nicht verstehen willst Ich habe eine 3/1 Aufteilung, also 3GB Prozess und 1GB Kernel. Es gibt allerdings im KernelSpace noch einen kleinen (8MB oder so) Prozess-lokalen Bereich für den User-VMM.

Bei einem 64Bit-OS trifft man ganz andere Entscheidungen. Dort wird man z.B. immer den gesamten physischen Speicher (mitsamt aller HW-Geräte) in den virtuellen Kernel-Adressraum 1:1 einblenden, einfach weil es bequem machbar ist und ne Menge grauer Haare erspart.

Du bist doch immer der, der meint das man auch einen Counter der erst in über 100Jahren überläuft so programmieren sollte, das man mit dem Fall umgehen kann. Aber du willst den physischen Speicher 1:1 mappen?
Was ist wenn in 100Jahren wieder die selbe Situation wie heute (also pyhsischer Speicher > virtueller unter 32bit) eingetreten ist? Mal ganz davon abgesehen, dass dann wahrscheinlich das ganze OS alles andere als noch geeignet sein wird.

Was ich mich noch frage ist warum Du überhaupt so wesentliche Teile Deines Kernels wie die Speicherverwaltung austauschbar haben willst.

Ich bastle gern und will halt mal zusehen, dass ich ein vernünftiges stabiles Interface zustande bekomme. Zumal ich mir halt so die Möglichkeit offen halte, einfach den Allocator austauschen zu können. Es gibt ja immer mal wieder richtig gute neue und dann habe ich nicht viel Aufwand meinen Kernel "anzupassen".

Soweit wie beim L4, wo man sagt das (fast) jede Architektur-Variante ihren eigenen speziell angepassten Kernel bekommt, muss man ja auch nicht unbedingt gehen

Ist es sehr schlecht wenn ich dir jetzt sage, dass das genau meine Meinung bei einem MikroKernel ist Der Kernel ist doch wirklich nicht so groß und da sollte man zusehen, dass man das beste aus der Architektur rausholt. Zumal ich kein Fan von den ganzen Präprozessor if´s, die es insbesondere im Linux-Kernel, aber auch in den meisten libc´s gibt.

Dann lieber komplett neuen angepassten Kernel, aber auch dort kann Code wieder verwendet werden. Allerdings nur wenn es ohne Präprozessor if´s geht.

Ich habe mir inzw. schon einige "wie schreibt man guten Code"-Bücher mal angeguckt und die verfolgen z.B. auch nen ganz anderes Ziel als optimalen binären Code. Der Code soll leicht lesbar sein und die Performance kommt erst irgendwann ganz ganz weit hinten.

Was ich damit sagen will, jeder hat so seine eigenen Ziele und mir gefällt es besser wenn diese Ebenen der Speicherverwaltung durch klar definierte Interfaces getrennt sind. Dass das auch Probleme gibt gehört halt zum Kompromiss dazu.

[erik.vikinger]

Hallo,


da momentan das Aufwärmen alter Threads gerade Mode ist will ich hier noch mal ansetzen.

Da habe ich dann mal wieder zu wenig Infos preisgegeben.

Ja. Du hast z.B. immer noch nicht angegeben wie groß der Bereich, den Dein Mini-Allocator verwaltet, eigentlich ist. Zum anderen halte ich es auch nicht für sinnvoll das statisch festzulegen, dieser Speicher ist dann für andere Zwecke verloren.
Wenn ich Dich richtig verstanden habe willst Du darin die Verwaltungsdaten für den Kernel-Heap unterbringen, richtig?

aber ich muss nicht Buch führen wie groß der freie Bereich ist oder ob noch genug frei ist, weil der Bereich der verwaltet wird groß genug für den worst-case ist (plus ein wenig mehr, um ein vernünftiges Alignment zu bekommen).

Also das erscheint mir etwas zu magisch, zumindest musst Du wissen wo Du neue Pages hinmappen kannst und Du solltest auch noch zumindest einen einfachen Integerwert haben der Dir sagt wie viel noch frei ist.

Dieser Allocator ist ein sehr vereinfachter SlabAllocator, halt nur ohne die große dynamische Verwaltung. Im Endeffekt könnte man sagen, dass ist das was du mir die ganze Zeit vorschlägst nur für nen ganz kleinen statisch festgelegten Bereich.

Nein, was ich verschlage ist den bereits vorhanden SLAB-Allocator für alles zu nutzen und nicht noch einen zusätzlichen (wenn auch primitiven) dazu zubauen.

Wenn ich Dich richtig verstanden habe willst Du doch das oberste GB des virtuellen Adressraums dem Kernel geben, das zweitoberste GB ist dann Prozess-lokal aber trotzdem nur für den Kernel zugänglich und der Prozess bekommt dann die unteren 2 GB.

Jetzt könnte ich auch schreiben, dass du mich einfach nicht verstehen willst Ich habe eine 3/1 Aufteilung, also 3GB Prozess und 1GB Kernel.

Du hast bisher gar keine konkreten Informationen über das Layout Deines virtuellen Adressraums gegeben, mit "Wenn ich Dich richtig verstanden habe" hab ich doch klar ausgedrückt das ich nur spekuliere.

Es gibt allerdings im KernelSpace noch einen kleinen (8MB oder so) Prozess-lokalen Bereich für den User-VMM.

Das heist dieser Bereich gehört noch zu dem oberen 1 GB aber es gibt dort für jeden Prozess individuelle PTs (also in jedem Prozess ist dort anderer physischer Speicher eingebunden)?

Du bist doch immer der, der meint das man auch einen Counter der erst in über 100Jahren überläuft so programmieren sollte, das man mit dem Fall umgehen kann. Aber du willst den physischen Speicher 1:1 mappen?

Ja, ich bin der Meinung das man an möglichst alle Eventualitäten denken sollte und genau deswegen würde ich in den Start-Code des Kernels eine Abfrage einbauen die prüft ob der tatsächlich benutzte physische Adressraum klein genug ist um in den virtuellen Adressraum des Kernels komplett und bequem rein zu passen ansonsten gibt es eine Fehlermeldung "To much Memory".

Das :

Zumal ich mir halt so die Möglichkeit offen halte, einfach den Allocator austauschen zu können.

und das :

Ist es sehr schlecht wenn ich dir jetzt sage, dass das genau meine Meinung bei einem MikroKernel ist Der Kernel ist doch wirklich nicht so groß und da sollte man zusehen, dass man das beste aus der Architektur rausholt.

widerspricht sich irgendwie. Auf der einen Seite möchtest Du möglichst viel Flexibilität und auf der anderen willst Du die Meinung vertreten das ein Micro-Kernel ruhig möglichst aus einem Guss sein soll, ich bin verwirrt.

Zumal ich kein Fan von den ganzen Präprozessor if´s, die es insbesondere im Linux-Kernel, aber auch in den meisten libc´s gibt.

Diese Einstellung findet meine uneingeschränkte Zustimmung.

mir gefällt es besser wenn diese Ebenen der Speicherverwaltung durch klar definierte Interfaces getrennt sind.

Dann musst Du aber auch alle indirekten Nebeneffekte mit berücksichtigen in Deiner Interface-Beschreibung (die zu diesem Zweck wirklich schriftlich erfolgen sollte damit Du auch in Jahren möglichst kein Detail aus den Augen verlierst). Ich hab bei mir z.B. mit beschrieben welche Locks frei sein müssen wenn bestimmte Funktionen mit bestimmten Parametern aufgerufen werden.


Grüße
Erik

[FlashBurn]

Ja. Du hast z.B. immer noch nicht angegeben wie groß der Bereich, den Dein Mini-Allocator verwaltet, eigentlich ist.

Doch, hast du weiter unten sogar gequotet Der ist ca. 8MB oder so groß, kann ich dir genau gar nicht sagen, weil das der Präprozessor (bzw. Templates) ausrechnet. Es wird aber auf 4MB gerundet, zwecks PTs.

Zum anderen halte ich es auch nicht für sinnvoll das statisch festzulegen, dieser Speicher ist dann für andere Zwecke verloren.
Wenn ich Dich richtig verstanden habe willst Du darin die Verwaltungsdaten für den Kernel-Heap unterbringen, richtig?

Jap, der Bereich ist zur Verwaltung des Kernel-Heaps da und er ist statisch zwecks Henne-Ei-Problem bzw. Kreis-Abhängigkeiten!

Also das erscheint mir etwas zu magisch, zumindest musst Du wissen wo Du neue Pages hinmappen kannst und Du solltest auch noch zumindest einen einfachen Integerwert haben der Dir sagt wie viel noch frei ist.

Also ja, ich habe ne Bitmap (für die gemappten Pages) und ne "verkettete Liste" (ist mehr nen Array mit verketteten Indizes). Soweit ich weiß führe ich nicht wirklich Buch wie viel noch frei ist. Ich habe mehr Speicher zur Verfügung als der worst-case ihn benötigt.

Nein, was ich verschlage ist den bereits vorhanden SLAB-Allocator für alles zu nutzen und nicht noch einen zusätzlichen (wenn auch primitiven) dazu zubauen.

Aber ich kann diesen SlabAllocator nicht einfach gegen z.B. dlmalloc austauschen ohne dlmalloc noch modifizieren zu müssen. Bei meiner Variante geht das und das war/ist mein Ziel.

Du hast bisher gar keine konkreten Informationen über das Layout Deines virtuellen Adressraums gegeben

Ich bin mir eigentlich ziemlich sicher das ich das in diesem Thread schonmal gepostet hatte.

Das heist dieser Bereich gehört noch zu dem oberen 1 GB aber es gibt dort für jeden Prozess individuelle PTs (also in jedem Prozess ist dort anderer physischer Speicher eingebunden)?

Jap, ist aber kein Problem da es immer ganze PTs sind.

Ja, ich bin der Meinung das man an möglichst alle Eventualitäten denken sollte und genau deswegen würde ich in den Start-Code des Kernels eine Abfrage einbauen die prüft ob der tatsächlich benutzte physische Adressraum klein genug ist um in den virtuellen Adressraum des Kernels komplett und bequem rein zu passen ansonsten gibt es eine Fehlermeldung "To much Memory".

Sorry, aber das wiederspricht sich mMn ja "alle Eventualitäten denken" und "Fehlermeldung "To much Memory"". Zumal du dann wieder genau das gleiche Problem wie der Linux-Kernel hast (und genau das will ich auch nicht). Du hast 64MB frei, brauchst 128KB, aber der größte zusammenhängende Bereich ist nur 64KB groß!

widerspricht sich irgendwie. Auf der einen Seite möchtest Du möglichst viel Flexibilität und auf der anderen willst Du die Meinung vertreten das ein Micro-Kernel ruhig möglichst aus einem Guss sein soll, ich bin verwirrt.

Aus meiner Sicht wiederspricht sich das nicht. Was ich bei dem MikroKernel für jede Architektur meinte ist doch, dass man alle Features so nutzt wie sie vorhanden sind (Hardware) und nicht andere drüber stülpt (Software) damit es auf allen Architekturen gleich ist.
Ich würde/werde für jede Architektur nen anderen HAL schreiben.

[erik.vikinger]

Hallo,

Doch, hast du weiter unten sogar gequotet Der ist ca. 8MB oder so groß ...

Aha, da hab ich wohl den Zusammenhang aus den Augen verloren, sorry.

und er ist statisch zwecks Henne-Ei-Problem bzw. Kreis-Abhängigkeiten!

Gut, das mit dem statisch kann ich zwar verstehen und nachvollziehen (Henne-Ei-Probleme und Kreis-Abhängigkeiten sind eklig) aber ist meiner persönlichen Meinung nach trotzdem ein wenig Verschwendung. Aber es ist Deine Design-Entscheidung und gut.

Sorry, aber das wiederspricht sich mMn ja "alle Eventualitäten denken" und "Fehlermeldung "To much Memory"".

Wo widerspricht sich das? Ich als Programmierer denke an die Eventualität das auch mal mehr physischer RAM im System sein könnte als mit dem im OS-Kernel implementierten Mechanismus sinnvoll verwaltet werden kann und deswegen fange ich das ab und gebe eine aussagekräftige Fehlermeldung. Ich denke das ist genau das was ich meine wenn ich sage das man als Programmierer auch mit ungewöhnlichen/unerwarteten/unmöglichen Randfällen umgehen sollte. Die maximale Menge an physischen Adressraum ist ja nichts was sich dynamisch zur Laufzeit ändert (deswegen muss man das auch nicht wie einen theoretisch überlaufenden Counter zur Laufzeit handhaben) sondern steht zur Boot-Zeit fest und das OS kann mit einer einzelnen Abfrage hier auf Nummer sicher gehen. An der selben Stelle im Boot-Code sollte auch noch eine Abfrage sein ob mindestens X MBytes an physischen RAM vorhanden sind damit das OS nicht schon beim Booten abstürzt.

Zumal du dann wieder genau das gleiche Problem wie der Linux-Kernel hast (und genau das will ich auch nicht). Du hast 64MB frei, brauchst 128KB, aber der größte zusammenhängende Bereich ist nur 64KB groß!

Hä, was meinst Du? Was hat die konkrete interne Speicherverwaltung im OS-Kernel damit zu tun wenn das OS beim Start prüft ob die Größe des benutzten physischen Adressraums für das OS im grünen Bereich liegt?

Ich würde/werde für jede Architektur nen anderen HAL schreiben.

Willst Du damit sagen das Deiner Meinung nach die Speicherverwaltung des OS-Kernels in den HAL gehört? Das erscheint mir persönlich doch etwas arg seltsam. Ich kenne im Embedded-Umfeld einige OSe die auf mehr als 10 verschiedenen CPU-Architekturen laufen und diese CPU-Architekturen haben oft nicht viel mehr gemeinsam als das der virtuelle Speicher mit Hilfe von klassischem Paging gemanaged wird. Wie z.B. die PT-Einträge aufgebaut sind oder wie groß die Pages sind kann sich unterschieden aber das wird nur mit einer CPU-Architektur-spezifischen .h-Datei geregelt und ansonsten ist der Code für die Speicherverwaltung immer der selbe. Die Basis-Mechanismen von Flat-Memory (also die Wirkungsweise von Paging) sind auf allen real existierenden CPUs so enorm ähnlich das es sich einfach nicht lohnt dafür unterschiedlichen Code zu schreiben. Es ist doch auch relativ egal ob die Pages 4kB oder 8kB groß sind oder ob ein x-stufiges Paging-Directory in Hardware benutzt wird oder ob das per SW emuliert wird.


Grüße
Erik

[FlashBurn]

Wo widerspricht sich das?

Naja, ich meine wozu? Unter 32bit kommst du ja auch nicht auf die Idee bei einer 2/2 Aufteilung, bei mehr als 2GB RAM ne Fehlermeldung zu schmeißen "Too much Memory". Ne Warnung könnte ich noch im höchstfall aktzeptieren, aber ne Fehlermeldung (was für mich Abbruch bedeutet)?!

An der selben Stelle im Boot-Code sollte auch noch eine Abfrage sein ob mindestens X MBytes an physischen RAM vorhanden sind damit das OS nicht schon beim Booten abstürzt.

Das ist übrigens nen sehr guter Hinweis (ob mindestens so viel Speicher vorhanden ist, dass das OS läuft) und ich habe schon einige Hobby OS´e gesehen die das nicht haben sondern einfach hängen bleiben.

Hä, was meinst Du? Was hat die konkrete interne Speicherverwaltung im OS-Kernel damit zu tun wenn das OS beim Start prüft ob die Größe des benutzten physischen Adressraums für das OS im grünen Bereich liegt?

Sorry, das bezog sich auf das 1:1 Mapping im Kernel.

Willst Du damit sagen das Deiner Meinung nach die Speicherverwaltung des OS-Kernels in den HAL gehört?

Kann sein das wir aneinander vorbei geredet haben, aber mir ging es darum, das ich vorhabe für jede Architektur nen extra Kernel zu haben, ohne Präprozessor Zeugs. Das dort gemeinsam genutzter Code ist, sollte klar sein (z.B. VMM und PMM, da ich immer von einer MMU also Paging ausgehe), aber ich werde für jede Architektur nen neuen HAL schreiben, weil es mMn keinen Sinn macht das Interface so allgemein zu halten das es auf wirklich jeder Architektur läuft. Was dann nach außen (was der Kernel also an Syscalls anbietet) sichtbar ist, dass wird überall gleich sein, nur die Implementierung wird eine andere Sein.

Mein Kernel ist im Moment z.B. verdammt stark auf x86 ausgerichtet und die Abläufe und Hardware-Initialisierung würde unter ARM so nicht umsetzbar sein. Alleine schon weil es unter ARM nen anderes Interrupt Konzept gibt.

Es ist doch auch relativ egal ob die Pages 4kB oder 8kB groß sind oder ob ein x-stufiges Paging-Directory in Hardware benutzt wird oder ob das per SW emuliert wird.

Ich bin mir nicht mehr sicher, aber der Linux-Kernel macht sowas in der Art (Software-Emulation der Paging-Hierarchie) und da bin ich absolut dagegen. Die "paar" Zeilen Code kann man ruhig richtig auf die Hardware anpassen.

[erik.vikinger]

Hallo,

Unter 32bit kommst du ja auch nicht auf die Idee bei einer 2/2 Aufteilung, bei mehr als 2GB RAM ne Fehlermeldung zu schmeißen "Too much Memory". Ne Warnung könnte ich noch im höchstfall aktzeptieren, aber ne Fehlermeldung (was für mich Abbruch bedeutet)?!

Ob Du es glaubst oder nicht, in meinem OS habe ich geplant in der 32 Bit-Version nicht mehr als 2 GB RAM zuzulassen. Mein Problem ist aber das ich in den 4 GB physischen Adressraum alles drin habe, alle Segmente aller Prozesse, der Kernel, sämtliche HW und dann brauch ich noch Reserve für den virtuellen Auslagerungsbereich wo die Segmente hin kommen wenn sie fragmentiert sind also Paging aktiv ist. Auf dem normalen x86-PC wird bei mehr als 2 GB RAM auch selten nur noch mit den Features des 386 gearbeitet, oft ist da PAE im Spiel, so das es sich streng genommen gar nicht mehr um echte 32 Bit-Systeme handelt. All diese Tricks hab ich aber nicht, ich lege einfach fest das wenn der RAM zu groß ist um vernünftig mit reinen 32 Bit-Features verwaltet zu werden dann muss eben ein 64 Bit-System her. Wenn Du Dir den Long-Mode mal genau anschaust wird Dir schnell auffallen dass das auch kein echter 64 Bit-Mode ist sondern das dort der virtuelle Adressraum auf 48 Bit (12 + 4*9) beschränkt ist. Wimre ist bei den neuesten AMD- und Intel-Prozis der physische Adressraum auf 56 Bit beschränkt (was die Fähigkeiten des Paging angeht, was also auch auf eine Art PAE hinaus läuft und auch entsprechenden Würgereiz verursacht) aber die Interfaces nach draußen können oft deutlich weniger, z.B. Hypertransport nur 40 Bit. Von daher bin ich schon der Meinung das es aus heutiger Sicht für absehbare Zeit Okay ist wenn man festlegt das der benutzte physische Adressraum maximal ein Viertel des virtuellen Kernel-Space (was ja auch nur die Hälfte des gesamten virtuellen Adressraums ist) betragen darf und sich dafür alle möglichen Krücken spart, so wie damals zu reinen 32 Bit-Zeiten. Damit kommt man mit heutigen x86-64-CPUs immerhin bis 32 TB und davon ist der Durchschnitts-PC noch einige Jahre entfernt, und wenn es mal so weit ist dann taugt das heutige OS eh nicht mehr viel so dass das Versagen dann (in > 20 Jahren) durchaus verschmerzbar ist.

Im Endeffekt ist Deine Entscheidung, Teile der Daten die eigentlich im virtuellen Kernel-Space liegen in den virtuellen Teil des jeweiligen Prozesses auszulagern, auch nur einer der möglichen Tricks um mit reinen 32 Bit-Mitteln möglichst dicht an 4 GB RAM heran zu kommen. Kann man so machen aber ich persönlich empfinde das als eher unelegant. Ich persönlich denke das auf einem Flat-Memory-System der physische RAM maximal ein Viertel des virtuellen Kernel-Space groß sein sollte damit man zuverlässig ohne Tricks auskommen kann. Dein Trick hat den Nachteil das Du nicht mehr im Kontext eines beliebigen Prozesses in der Verwaltung des virtuellen Adressraum eines anderen beliebigen Prozesses was ändern kannst, andere Tricks haben andere Nachteile, daher meine generelle Ablehnung solcher Tricks.

Kann sein das wir aneinander vorbei geredet haben

Oh ja, es ging doch eigentlich darum das Du eine austauschbare Speicherverwaltung für Deinen Micro-Kernel möchtest und ich der Meinung bin das die Speicherverwaltung in einem Micro-Kernel so zentral ist dass das Austauschen keinen Sinn ergibt. Klar muss man bestimmte Dinge hinter einem HAL verstecken wenn das OS auf wirklich verschiedenen CPU-Architekturen laufen soll aber das ist doch gar nicht das Thema dieser Teil-Diskussion gewesen.

Ich bin mir nicht mehr sicher, aber der Linux-Kernel macht sowas in der Art (Software-Emulation der Paging-Hierarchie) und da bin ich absolut dagegen. Die "paar" Zeilen Code kann man ruhig richtig auf die Hardware anpassen.

Ich denke mit was anderem als einer Software-Abstraktion bekommt man so unterschiedliche CPU-Architekturen (was die konkrete Implementierung des Paging angeht) wie x86, x86-64, ARM und SPARC kaum unter einen Hut und da die Speicherverwaltung des Linux-Kernel deutlich mächtiger und umfangreicher als die eines typischen Micro-Kernel ist lohnt es sich IMHO durchaus da passend zu abstrahieren um die Speicherverwaltung immer gleich lassen zu können.


Grüße
Erik

[FlashBurn]

davon ist der Durchschnitts-PC noch einige Jahre entfernt, und wenn es mal so weit ist dann taugt das heutige OS eh nicht mehr viel so dass das Versagen dann (in > 20 Jahren) durchaus verschmerzbar ist.

Oh, oh, dass heißt doch wiederrum das es auch nicht schlimm ist, wenn irgendein Counter in 20 Jahren mal überläuft, ist doch verschmerzbar

Im Endeffekt ist Deine Entscheidung, Teile der Daten die eigentlich im virtuellen Kernel-Space liegen in den virtuellen Teil des jeweiligen Prozesses auszulagern, auch nur einer der möglichen Tricks um mit reinen 32 Bit-Mitteln möglichst dicht an 4 GB RAM heran zu kommen.

Ich wollte den Trick nutzen, um meine Limits für alle möglichen Ressourcen so hoch wie möglich zu setzen, auch wenn es praktisch wahrscheinlich keinen Sinn geben wird. Vorallem nicht da ja die Treiber ihren eigenen Adressraum haben und das nicht auch noch im Kernel sein muss.

Oh ja, es ging doch eigentlich darum das Du eine austauschbare Speicherverwaltung für Deinen Micro-Kernel möchtest und ich der Meinung bin das die Speicherverwaltung in einem Micro-Kernel so zentral ist dass das Austauschen keinen Sinn ergibt.

Da sind wir halt wieder unterschiedlicher Meinung, aber ich habe das ganze soweit abstrahiert, dass ich einfach mal um die Performance verschiedener Methoden zu testen, nur den neuen Allocator nehmen muss und 2 Funktionsaufrufe (valloc() und vfree()) anpassen muss. Ansonsten wird ja das meiste mit new (C++) gemacht und die überschriebenen Methoden müssten noch angepasst werden und schon habe ich mit verdammt wenig Aufwand nen anderen Allocator integriert. Das wäre bei deinem Konzept nicht möglich, da wäre viel mehr Aufwand für nötig.

Was das mit dem HAL betrifft, da ging es mir darum, dass ich einen neuen Kernel für jede Architektur schreiben möchte. Hat mit dem VMM erstmal nix zu tun, zumal der ja fast vollständig (Umsetzung des Pagings) übernommen werden kann.

Ich denke mit was anderem als einer Software-Abstraktion bekommt man so unterschiedliche CPU-Architekturen (was die konkrete Implementierung des Paging angeht) wie x86, x86-64, ARM und SPARC kaum unter einen Hut und da die Speicherverwaltung des Linux-Kernel deutlich mächtiger und umfangreicher als die eines typischen Micro-Kernel ist lohnt es sich IMHO durchaus da passend zu abstrahieren um die Speicherverwaltung immer gleich lassen zu können.

An was denkst du da mit mächtiger? Ich denke mal die machen das nur weil es sich bei einem Monolithen halt nicht vermeiden lässt, ansonsten wird das zu aufwändig.

Da ist auch ganz eindeutig mMn ein MikroKernel im Vorteil. Vorallem geht durch die Software-Emulation ja Speicher und Performance verloren (was ja nun wirklich der worst-case ist).

Du bist gar nicht auf die Nachteile eines 1:1 Mappings eingegangen. Welche Vorteile bringt das eigentlich? Ich meine im Linux-Kernel werden ja ganz schöne Verrenkungen gemacht, damit es nutzen kann.

[erik.vikinger]

Hallo,


Deine Latenz ist mal wieder beängstigend kurz.

Oh, oh, dass heißt doch wiederrum das es auch nicht schlimm ist, wenn irgendein Counter in 20 Jahren mal überläuft, ist doch verschmerzbar

Nein, Du versuchst hier Äpfel mit Birnen zu vergleichen. Es ist auf jeden Fall ein Unterschied ob eine SW nach 20 Jahren Laufzeit (auf immer dem selben Computer der dann auch 20 Jahre alt ist) abstürzt oder ob ein heutiges Programm auf einen Computer der erst in 20 Jahren überhaupt gebaut werden kann nicht mehr funktioniert. Ersteres kann in einer Katastrophe enden wogegen letzteres ein normales Phänomen des technischen Fortschritts darstellt und eben grundsätzlich nicht zu einer Katastrophe führen kann weil diese unheilige Konstellation aus alter SW und neuem Computer erst gar nicht anläuft so das erst gar keine kritischen Tasks drauf laufen können. Es wäre IMHO auch ein Bug wenn ich einen heutigen Computer mit heutiger SW als tauglich teste, das ganze dann für 20 Jahre in den Schrank packe und wenn ich das irgendwann mal brauche es plötzlich nicht mehr geht. Aber eine neue Zusammenstellung muss immer erst getestet werden bevor man damit kritische Aufgaben erledigen will.

Meiner Meinung nach wäre es deutlich schlimmer wenn die alte SW auf dem neuen Computer ohne sichtbare Warnung o.ä. anläuft aber dann irgendwann einfach abstürzt weil sie mit dem neuen Computer eben doch nicht gescheit umgehen kann, da ist mir eine klare Fehlermeldung deutlich lieber, oder?

Ich wollte den Trick nutzen ....

Schon klar, aber dieser Trick kostet Dich was und da musst Du erst mal überlegen ob das Preis-Leistung-Verhältnis stimmt.

Das wäre bei deinem Konzept nicht möglich, da wäre viel mehr Aufwand für nötig.

Ja, aber bei meinem Kernel dürfte die Speicherverwaltung (vor allem weil da Dinge wie das Defragmentieren usw. mit reinspielen) die zentrale Hauptkomponente des Kernels sein so das wenn ich das austauschen wollte das ich denn eh mehr als 50% des Quell-Codes tausche und da muss ich dann ehrlich sagen das es IMHO Quatsch ist wenn der Schwanz mit dem Hund wedelt.

An was denkst du da mit mächtiger? Ich denke mal die machen das nur weil es sich bei einem Monolithen halt nicht vermeiden lässt, ansonsten wird das zu aufwändig.

So weit ich weiß ist der Heap im Linux-Kernel (also kmalloc/kfree) durchaus sehr leistungsfähig und flexibel, natürlich ist das auch ein Zwang des Monolithen weil da ja mehr als eine kleine Hand voll an verschiedenen Objekt-Größen vorkommen und die HW-Treiber ja noch mal zusätzliche Anforderungen haben (was beides bei einem Micro-Kernel nicht zutrifft).

Du bist gar nicht auf die Nachteile eines 1:1 Mappings eingegangen. Welche Vorteile bringt das eigentlich?

Der Nachteil des 1:1 Mappings ist ganz klar das man einen, im Verhältnis zum physischen Speicher, recht großen virtuellen Kernel-Space benötigt bzw. andersherum das der maximale physische Speicher signifikant kleiner sein muss als der virtuelle Kernel-Space. Der Vorteil ist das man alle PDs usw. problemlos modifizieren kann ohne irgendwelche Verrenkungen unternehmen zu müssen, alles was irgendwie in den Kernel gehört ist auch immer, von jedem Kontext aus, im Kernel-Space erreichbar. Den Teilbereich des virtuellen Kernel-Space wo der physische Speicher 1:1 gemappt wird könnte man sogar statisch festlegen so das man hier auch keine dynamischen Adressen o.ä. benötigt. Mir persönlich wäre das genug damit ich mich bei einem Flat-Memory-OS genau dafür entscheiden würde. Aber es wäre ja auch langweilig wenn jeder seine Entscheidungen so treffen würde wie ich das zu tun pflege.


Grüße
Erik

[FlashBurn]

Den Teilbereich des virtuellen Kernel-Space wo der physische Speicher 1:1 gemappt wird könnte man sogar statisch festlegen so das man hier auch keine dynamischen Adressen o.ä. benötigt. Mir persönlich wäre das genug damit ich mich bei einem Flat-Memory-OS genau dafür entscheiden würde. Aber es wäre ja auch langweilig wenn jeder seine Entscheidungen so treffen würde wie ich das zu tun pflege.

Damit gibst du ja den großen Vorteil von Paging auf nämlich das Umgehen der Fragmentierung des physischen Speichers.

Das große Problem welches der Linux-Kernel halt hat, ist wie mein Bsp. von weiter oben, man hat 64MB freien RAM, der Kernel braucht 128KB zusammenhängenden freien Speicher, aber es gibt nur noch 64KB zusammenhängenden freien Speicher. Das ist doch absurd und sowas willst du?

[erik.vikinger]

Hallo,

Damit gibst du ja den großen Vorteil von Paging auf nämlich das Umgehen der Fragmentierung des physischen Speichers.

Da hast Du mich wohl miss verstanden. Ich meine nicht das der Kernel wirklich in dem 1:1 gemappten Teil selber lebt sondern der Kernel benutzt den Rest seines virtuellen Kernel-Space (deshalb darf der physische Speicher nur einen Teil des Kernel-Space belegen) so wie alle anderen Kernel auch, er nutzt nur den 1:1 Teil um darin z.B. die PDs zu manipulieren. In jedem Prozess-Descriptor benötigt man doch die physische Adresse des jeweiligen PD-Roots, die kommt ja schließlich auch ins CR3, und wenn man da einfach die statisch festgelegte virtuelle Start-Adresse des 1:1 Bereichs drauf addiert kann man das gesamte PD manipulieren wie man will (die enthaltenen physischen Adressen auf die untergeordneten Tabellen-Ebenen kann man wieder einfach mit einer Addition in eine gültige virtuelle Kernel-Space-Adresse umwandeln). Da alle Prozess-Descriptoren im normalen virtuellen Kernel-Space liegen (und damit aus jedem Kontext erreichbar sind) kann man auch immer an jedem beliebigen PD was ändern. So beliebte Tricks wie das der letzte Eintrag im Root-PD auf sich selbst zeigt damit in den letzten 4MB das PD und alle PTs enthalten sind ist damit hinfällig, dieser Trick hat ja auch wieder den Nachteil das damit immer nur das aktuelle PD manipulierbar ist.

Was Du immer mit Deinem zusammenhängen Speicher willst verstehe ich nicht. Mir fällt auf einem aktuellen PC mit einem Flat-Memory-OS absolut kein Grund ein physisch zusammenhängenden Speicher zu benötigen, nebst dessen dass das IMHO nichts mit der konzeptionellen Aufteilung des virtuellen Kernel-Space zu tun hat.


Grüße
Erik

[FlashBurn]

Was Du immer mit Deinem zusammenhängen Speicher willst verstehe ich nicht. Mir fällt auf einem aktuellen PC mit einem Flat-Memory-OS absolut kein Grund ein physisch zusammenhängenden Speicher zu benötigen, nebst dessen dass das IMHO nichts mit der konzeptionellen Aufteilung des virtuellen Kernel-Space zu tun hat.

Ich hänge mich da wahrscheinlich zu sehr an dem 1:1 Mapping und an der Art und Weise wie es in Linux umgesetzt ist auf. Die benutzen ja nen Buddy-Allocator und mappen auf x86 bis 768MB (glaub ich) 1:1. D.h. dann halt das du so nette Probleme wie das Bsp. was ich jetzt schon mehrmals gebracht habe, bekommst und deshalb mag ich das mit dem 1:1 Mapping nicht. Ich bin dabei aber auch davon ausgegangen, dass das dann wirklich 1:1 ist, also physisch == virtuell.

Ich bin mir nicht sicher, aber für nen Monolithen dürfte das doch auch Probleme geben, wenn alle PDs gemappt sind und dann auch noch die ganze Hardware, da stößt du doch relativ schnell (vorallem heute) and die 1GB Grenze und dann würde eine 2/2 Aufteilung (wie meistens bei x86 Windows) ja wieder besser sein.

[erik.vikinger]

Hallo,


ich wuste gar nicht das Linux größere Mengen Speicher 1:1 mappt. Wirklich mit virtuell == physisch? Das kann ich mir ehrlich gesagt nicht so gut Vorstellen, Linux benutzt doch auch einen Higher-Half-Kernel oder?
Sorry, das ich mich da unklar ausgedrückt habe, mit 1:1 meinte ich nicht virtuell == physisch sondern nur das der tatsächlich benutzte physische Adressraum (der ja kleiner sein muss als die Plattform eigentlich kann) irgendwo als ganzes lineares Stück im virtuellen Adressraum (in dem Teil der zum Kernel-Space gehört) zu finden ist.

Da kommt mir die Idee das wenn man einen Lower-Half-Kernel machen würde dann würde das sogar echt gehen, tät immerhin die Additionen ersparen und bei einem Monolithen würden sicher auch die enthaltenen Treiber profitieren wenn Sie ihre HW direkt mit der physischen Adresse ansprechen können ganz ohne Umrechnung o.ä., man müsste den virtuellen Adressraum einfach so aufteilen dass das unterste Viertel dem 1:1 Bereich gehört, das nächste Viertel wäre dann der normale Kernel-Space und die obere Hälfte wäre dann Prozess-spezifischer User-Mode. Ich denke das könnte richtig gut funktionieren aber ich mach ja gar kein Flat-Memory-OS.


Grüße
Erik