Thema: Eigene CPU

[Programm Noob]

Moin

Entschuldigung, das ich deine Segmentierung nicht gut finde.

Dafür brauchst Du Dich nicht zu entschuldigen, mit Meinungen hab ich kein Problem. Ich hab ein Problem damit das Du ein Konzept das Du nicht kennst als "verrückt" abstempelst ohne das rational zu begründen.

Ich habe deine Threads bisher alle so ziemlich komplett durchgelesen. aber ich glaube ich habe dein Konzept nicht so ganz verstanden. Ich sehe da irgendwie keinen Vorteil gegenüber der x86 Realmode Segmentierung.
auch verstehe ich nicht, wie du die Segmente verwalten willst, also welche Segmente u welchem Task gehören.

PNoob

[kevin]

Mit PM-Segmentierung kann man aber noch viel lustigere Sachen machen.

Das ist die richtige Einstellung! Willst Du nicht bei mir einsteigen? Ein Paar fähige Hände könnte ich gut gebrauchen und als Gegenleistung darfst Du mit einem signifikant erweiterten Horizont rechnen.

Danke, aber i386 ist mir krank genug und ich habe es noch nicht einmal annähernd durchgespielt.

[MasterLee]

zu der 32 bit cpu: sie kann leider der ram nur mit einem 24 bit adressbus ansprechen, da logisim meint: "Neh du brauchst nicht mehr als 16.777.215 32bit zellen speicher ...."

Nimm einfach mehrere RAM Bausteine ein Verteiler und einen Demuxer denn du dann mit denn sel Anschluss des RAM verbindest.

[erik.vikinger]

Hallo,

aber ich glaube ich habe dein Konzept nicht so ganz verstanden.

Dann habe ich meine Ideen wohl zu kompliziert beschrieben, das tut mir leid.

Ich sehe da irgendwie keinen Vorteil gegenüber der x86 Realmode Segmentierung.

Die x86-Real-Mode-Segmentierung ist starr, da gibt es keine Flexibilität: wo das Segment im Speicher liegt ist durch den numerischen Wert des Selector bereits festgelegt und auch die Größe ist fix. Bei dynamischen Segmenten kannst du für jedes Segment beliebig definieren wo es im linearen Speicher liegt und wie groß es ist. Man kann z.B. für einen Stack ein Segment mit 16 kBytes als Startgröße nehmen und wenn der Thread doch mehr Stack benötigt dann kann man das Segment einfach vergrößern und wenn das Vergrößern an der aktuellen Stelle im linearen Speicher nicht geht dann kann man das Segment auch kurzerhand wo anders hin legen (und dann später in aller Ruhe im Hintergrund den linearen Speicher defragmentieren) ohne das der betreffende Thread das überhaupt bemerkt. Und da ja jeder Prozess seine eigene LDT hat kommt da auch nichts durcheinander und es gibt damit einen starken Speicherschutz obwohl alle Segmente von allen Prozessen im selben linearen Speicher liegen. Das geht alles nur mit dynamischen und flexiblen Segmenten. All das kann der 386 im PM prinzipiell auch, wenn auch manches davon nicht so elegant wie meine CPU das können soll (nebst dessen das seine nur 6 Segmentregister einfach ein Performance-Engpass darstellen).

auch verstehe ich nicht, wie du die Segmente verwalten willst, also welche Segmente u welchem Task gehören.

Jeder Prozess hat seine eigene LDT und in der stehen alle Segmente des betreffenden Prozess drin. Also ein Execute-Only-Segment mit dem Code, ein Write-Only-Segment für .const ein Read-Write-Segment mit .data und .bss (im Executable muss natürlich nur .data drin sein) und für jeden Thread noch ein Stack-Segment und ein TLS-Segment (bis auf die Stack-Segmente wird die Größe all dieser Segmente zur Laufzeit nicht mehr geändert). Dazu kommen noch die Segmente aus denen die Heap-Verwaltung eben den Heap baut (die Größe dieser Segmente wird natürlich zur Laufzeit dem Bedarf entsprechend angepasst).

Wenn Du konkrete Fragen hast dann stell sie einfach, wir sind ja hier im richtigen Thread dafür.

Danke, aber i386 ist mir krank genug und ich habe es noch nicht einmal annähernd durchgespielt.

Schade das Du das so negativ siehst (obwohl ich damit eigentlich gerechnet habe), Du weißt ja gar nicht was Dir alles entgeht, Dein Pech.


Grüße
Erik

[Programm Noob]

aber ich glaube ich habe dein Konzept nicht so ganz verstanden.

Dann habe ich meine Ideen wohl zu kompliziert beschrieben, das tut mir leid.

Eine eigene Archtitektur ist zu kompliziert, die kann man schlecht beschriben. nicht umsonst sind die Intel Manuals so groß. Es ist nicht dein Fehler.

auch verstehe ich nicht, wie du die Segmente verwalten willst, also welche Segmente u welchem Task gehören.

Jeder Prozess hat seine eigene LDT und in der stehen alle Segmente des betreffenden Prozess drin. Also ein Execute-Only-Segment mit dem Code, ein Write-Only-Segment für .const ein Read-Write-Segment mit .data und .bss (im Executable muss natürlich nur .data drin sein) und für jeden Thread noch ein Stack-Segment und ein TLS-Segment (bis auf die Stack-Segmente wird die Größe all dieser Segmente zur Laufzeit nicht mehr geändert). Dazu kommen noch die Segmente aus denen die Heap-Verwaltung eben den Heap baut (die Größe dieser Segmente wird natürlich zur Laufzeit dem Bedarf entsprechend angepasst).

Was ist eine LDT?

Wenn Du konkrete Fragen hast dann stell sie einfach, wir sind ja hier im richtigen Thread dafür.

Ich werde mir nacher alles nochmal durchlesen und dann auch fragen stellen.

Danke, aber i386 ist mir krank genug und ich habe es noch nicht einmal annähernd durchgespielt.

Schade das Du das so negativ siehst (obwohl ich damit eigentlich gerechnet habe), Du weißt ja gar nicht was Dir alles entgeht, Dein Pech.

Erik deine Architektur ist einfach zu anders. und da hier alle schon mit der x86 RealMode Segmentierung in Berührung gekommen sind, mögen die Leute keine Segmentierung.

PNoob

[MNemo]

Erik deine Architektur ist einfach zu anders. und da hier alle schon mit der x86 RealMode Segmentierung in Berührung gekommen sind, mögen die Leute keine Segmentierung.

Naja, der RM hat bei mir da keinen Einfluss drauf, wenn man diese Form der Adressraumerweiterung überhaupt Segmentierung nennen darf. Prinzipiell sind Segmente auch was tolles.<edit> Ich sehe nur alle Vorteile durch die Verwaltung von Segmenten wieder zu Nichte gemacht.Ich halt nur den Aufwand die Segmente zu Verwalten für größer als ihren Nutzen.</edit> Man muss den RAM ständig defragmentieren.
Dazu sehe ich nur die zwei Möglichkeiten:
- Paging, womit das ganze transparent ablaufen kann
- oder, das gesamte Segment blockieren bis es fertig verschoben ist.

Bei ersterem, gibt es keinen Geschwindigkeitsvorteil gegen über Paging, weil man ja Paging benutzt.
(Hier bin ich ein wenig verwirrt, weil ich es irgend wie so mitkommen habe, dass Eriks Wahl ist.*)
Letzteres wird vermutlich schwere negative Auswirkungen auf die Performance haben.

Und wenn ich auf ein Flat-memory-model zurückgreife, hab ich zwar keine Abgrenzung mehr zwischen Code, Daten und Stack. Aber ich kann jetzt defragmentieren wenn es gerade günstig ist. Und wenn man dann auf 4MB oder sogar 1GB Pages 'hoch schalten' kann müssten sich die TLB'misses beim Pagelookup auch drastisch reduzieren.

*Aber ich hab seine Romane auch nicht komplett gelesen.

[kevin]

Wenn ich Erik richtig verstanden habe, will er Paging nur einschalten, solange er swappt/defragmentiert und hinterher wieder ausschalten. Was natürlich ein ganzer Haufen Aufwand ist, nur um diese eine Operation durchzuführen.

ein Write-Only-Segment für .const

Sicher?

Danke, aber i386 ist mir krank genug und ich habe es noch nicht einmal annähernd durchgespielt.

Schade das Du das so negativ siehst (obwohl ich damit eigentlich gerechnet habe), Du weißt ja gar nicht was Dir alles entgeht, Dein Pech.

Naja, im Ernst: Das tolle am x86 ist, dass ich ihn mehrfach vorrätig habe und damit ohne weiteres rumspielen kann. Dass du mehr oder weniger im luftleeren Raum jahrelang rumplanst und bastelst, bevor man an irgendwelche echten Ergebnisse auch nur denken kann, nötigt mir Respekt ab, aber ich kann das nicht. Ich brauche was zum rumspielen.

Was ist eine LDT?

Local Descriptor Table, also sowas wie die GDT, nur hat jeder Prozess eine eigene davon. Lies dir mal das Intel-Manual durch, der Protected Mode hat viele interessante Sachen. Wenn du den PM einigermaßen verstanden hast, wirst du Eriks Architektur auch besser nachvollziehen können.

[chris12]

zu der 32 bit cpu: sie kann leider der ram nur mit einem 24 bit adressbus ansprechen, da logisim meint: "Neh du brauchst nicht mehr als 16.777.215 32bit zellen speicher ...."

Nimm einfach mehrere RAM Bausteine ein Verteiler und einen Demuxer denn du dann mit denn sel Anschluss des RAM verbindest.

kann ich machen, nur müsste ich dann den source code bzw das binäre programm entsprechend aufteilen und dazu hatte ich noch keine lust sowas einzubauen ^^
aber eine gute idee, danke

[erik.vikinger]

Hallo,

Erik deine Architektur ist einfach zu anders.

Das soll sie ja auch sein.

und da hier alle schon mit der x86 RealMode Segmentierung in Berührung gekommen sind, mögen die Leute keine Segmentierung.

Das ist wohl eher das Problem. Intel hat mit seinem vermurksten Real-Mode die Leute eher abgeschreckt. Im PM blendet man die Segmentierung für gewöhnlich einfach aus und kommt daher quasi gar nicht damit in Berührung. Ich hab im 386-PM schon einiges mit Segmentierung machen dürfen, z.B. im Rahmen von verschiedenen DOS-Extendern, und hab dabei auch die Vorzüge kennen gelernt.

Ich sehe nur alle Vorteile durch die Verwaltung von Segmenten wieder zu Nichte gemacht. Man muss den RAM ständig defragmentieren.

Wieso sollte die Verwaltung von Segmenten kompliziert sein? Das sind auch nur zusammenhängende Bereiche im linearen Adressraum, das ist IMHO nicht komplexer als ein HEAP der auch zusammenhänge Bereiche unterschiedlicher Größe in seinem einen virtuellen Adressraum (der ja auch linear ist) verwaltet. Defragmentieren muss man auch nicht "ständig" sondern nur wenn es nötig ist, bei einem kaum belasteten System sollte das entsprechend selten sein.

Dazu sehe ich nur die zwei Möglichkeiten:
- Paging, womit das ganze transparent ablaufen kann
- oder, das gesamte Segment blockieren bis es fertig verschoben ist.

Exakt. Ich habe mich für Paging entschieden weil die zweite Option wohl wirklich nicht in frage kommt. Damit mir das Paging nicht die Performance (von der ich ja immer schwärme) kaputt macht wird es nur zum defragmentieren/swappen eingeschaltet und auch nur für die Segmente die davon betroffen sind, alle anderen Segmente bleiben davon verschont.

Und wenn man dann auf 4MB oder sogar 1GB Pages 'hoch schalten' kann müssten sich die TLB'misses beim Pagelookup auch drastisch reduzieren.

Genau das kann man aber nur selten machen, das geht für einen großen Batzen an Code oder für die .data-Sektion aber z.B. für Stacks ist das nur wenig praktikabel denn wenn Du im virtuellen Adressraum eine große Page anbietest musst Du auch den physischen Speicher dafür haben (und zwar passend ausgerichtet). Da der virtuelle Adressraum typischer Flat-Memory-Programme oft nur dünn belegt ist kommen die großen Pages eben kaum zum Einsatz.

*Aber ich hab seine Romane auch nicht komplett gelesen.

Daraus macht Dir wirklich niemand einen Vorwurf.
Manche meiner Beiträge sind schon wirklich extrem lang, aber Segmentierung ist eben nichts alltägliches und da muss man manche Kleinigkeiten schon etwas ausführlicher erklären.

Was natürlich ein ganzer Haufen Aufwand ist, nur um diese eine Operation durchzuführen.

Wo ist das ein Aufwand? Ich muss doch nur ein Mapping einrichten und dafür ist der Aufwand erstmal nur direkt abhängig von der Größe des betreffenden Speicherblocks, das ist auf Flat-Memory-Systemen doch ganz genau so. Das Paging ist immer da und wird dann nur für das eine Segment eingeschaltet, ich hab da ein extra Bit im Segment-Descriptor vorgesehen. Irgendwo in diesem Thread hab ich mal erklärt wie ich mir das vorstelle was alles passieren muss wenn ein Segment vergrößert werden soll aber etwas im Weg ist, klar ist da erst mal ein gewisser Aufwand aber dann läuft das eigentliche Defragmentieren bequem und unbemerkt im Hintergrund ab.

ein Write-Only-Segment für .const

Sicher?

Mist, das muss natürlich Read-Only heißen. Aber es wird bei mir auch Write-Only-Segmente geben z.B. für IPC wenn der Service in einen Bereich nur Daten rein legen soll.

Das tolle am x86 ist, dass ich ihn mehrfach vorrätig habe und damit ohne weiteres rumspielen kann.

Okay, das ist natürlich ein gutes Argument.

Dass du mehr oder weniger im luftleeren Raum jahrelang rumplanst und bastelst, bevor man an irgendwelche echten Ergebnisse auch nur denken kann, nötigt mir Respekt ab

Naja, das erste mal lief bereits vor gut 2 ein wenig händisch assemblierter Code in einem noch extrem primitiven Simulator, die OpCodes händisch zusammen zu bauen war alles andere als angenehm. Genau deswegen will ich ja jetzt endlich einen Assembler, ich denke wenn der zuverlässig Code ausspuckt geht der Rest wieder deutlich zügiger voran. Nur sollte ich mir bis da hin mit meinen OpCodes und Descriptor-Tabellen recht sicher sein ansonsten muss ich an vielen Stellen Code anfassen.

Lies dir mal das Intel-Manual durch, der Protected Mode hat viele interessante Sachen. Wenn du den PM einigermaßen verstanden hast, wirst du Eriks Architektur auch besser nachvollziehen können.

Ja, das stimmt, ich habe vom 386-PM viele Ideen übernommen (eine gewisse Ähnlichkeit ist nicht abzustreiten). Ich denke auch das ein Großteil meiner Ideen für das OS auf dem 386 ebenfalls funktionieren können. Der größte Unterschied ist das ich das Paging pro Segment einschalten kann und das es vor allem nur eines gibt (also alle Prozesse im selben linearen Adressraum existieren), ansonsten existiert noch der Unterschied das ich von vornherein 64Bit mit integriert habe (als AMD den Long-Mode erschaffen hat wurden ja all die tollen Sachen raus geworfen).


Grüße
Erik

[MNemo]

Ich sehe nur alle Vorteile durch die Verwaltung von Segmenten wieder zu Nichte gemacht. Man muss den RAM ständig defragmentieren.

Wieso sollte die Verwaltung von Segmenten kompliziert sein? Das sind auch nur zusammenhängende Bereiche im linearen Adressraum, das ist IMHO nicht komplexer als ein HEAP der auch zusammenhänge Bereiche unterschiedlicher Größe in seinem einen virtuellen Adressraum (der ja auch linear ist) verwaltet. Defragmentieren muss man auch nicht "ständig" sondern nur wenn es nötig ist, bei einem kaum belasteten System sollte das entsprechend selten sein.

Solange man nicht defragmentieren muss, ist alles ganz easy. Nur gehe ich davon aus, dass das mit dem Defragmentieren nicht ganz so selten sein wird, und vor allem immer dann wenn es gerade auf Performance ankommt. Also wenn man z. B. gerade ein 'make -j5 bzimage' im Hintergrund laufen lässt, könnte ich mir vorstellen, dass der RAM  ziemlich zerhackt wird. Es sei den bis du fertig bist hat jemand nen GCC-Daemon gebaut, der dir das Erstellen von Tausenden neuen unterschiedlich großen Segmenten erspart.

Und wenn man dann auf 4MB oder sogar 1GB Pages 'hoch schalten' kann müssten sich die TLB'misses beim Pagelookup auch drastisch reduzieren.

Genau das kann man aber nur selten machen, das geht für einen großen Batzen an Code oder für die .data-Sektion aber z.B. für Stacks ist das nur wenig praktikabel denn wenn Du im virtuellen Adressraum eine große Page anbietest musst Du auch den physischen Speicher dafür haben (und zwar passend ausgerichtet). Da der virtuelle Adressraum typischer Flat-Memory-Programme oft nur dünn belegt ist kommen die großen Pages eben kaum zum Einsatz.

Code und Datenbereich sind das worauf es ankommt. Der Stack wird sich nur selten in einem Bereich größer 4KB bewegen, und so sowieso nur eine TLB'miss auslösen. Und das mit der passende Ausrichtung lässt sich ja machen.

*Aber ich hab seine Romane auch nicht komplett gelesen.

Daraus macht Dir wirklich niemand einen Vorwurf.

Da bin ich aber beruhigt.

[erik.vikinger]

Hallo,

der dir das Erstellen von Tausenden neuen unterschiedlich großen Segmenten erspart.

Warum sollten den "tausende" Segmente für ein paar Compiler-Instanzen nötig sein?

Ansonsten hast Du natürlich recht das fragmentierte Segmente gerade dann entstehen wenn Performance benötigt wird. Aber das Problem trifft doch Flat-Memory-Systeme genau so. Speicher wird üblicherweise dann angefordert wenn er auch benötigt wird und dann muss das OS dem so schnell als möglich nachkommen. In einem Flat-Memory-System musst Du ein Mapping anlegen (und dafür im Zweifelsfall ne Menge einzelner physischer Pages aus dem wahrscheinlich ziemlich zerklüfteten physischen Speicher zusammensuchen), das kann man kurzsichtig etwas beschleunigen indem nur der virtuelle Adressraum belegt wird und das eigentliche Mapping dann später über unzählige und teure (daher kurzsichtig) Page-Faults nachholt. Wenn ich ein Segment anlegen muss kann ich prüfen ob das sofort in einem Stück geht (wäre der Optimalfall) oder ob es fragmentiert entstehen muss und dann muss ich ebenso ein Mapping anlegen und hab dabei auch die selben kurzsichtigen Beschleunigungsoptionen. Damit der Optimalfall möglichst oft eintritt kann ich im Hintergrund prophylaktisch defragmentieren aber das lohnt sich IMHO nur wenn der lineare Speicher auch bereits nennenswert ausgelastet oder stark zerklüftet ist (und das ist wohl nur selten).

Code und Datenbereich sind das worauf es ankommt.

Und was ist mit dem Heap, der ist in klassischen Flat-Memory-System auch oft ziemlich zerklüftet.

Der Stack wird sich aber nur selten in einem bereich größer 4KB bewegen.

Das würde ich nicht unbedingt so sehen. Klar wissen viele Programmierer um die Stackknappheit aber es gibt trotzdem viele Situationen wo man mal tiefe Call-Trees erzeugt oder einfach mal einen dicken Batzen Daten als lokale Variablen anlegt. Der Punkt ist das man mit Flat-Memory diese Dynamik nur unzureichend abfangen kann: entweder man macht die Stacks zu klein um mehr Threads zu ermöglichen und riskiert damit eben ein Out-of-Stack oder man macht die Stacks größer und begrenzt dadurch die maximale Anzahl möglicher Threads. Ein Dilemma das eben daraus entsteht das der virtuelle Adressraum in einem Flat-Memory-Prozess nur genau ein mal existiert, das dieses Dilemma keine spürbaren Auswirkungen hat liegt vor allem daran das die meisten Programmierer mit Stack und Threads sparsam umgehen.

Und das mit der passende Ausrichtung lässt sich ja machen.

Und wie? Mit defragmentieren? Welches Flat-Memory-OS macht das denn?


Grüße
Erik

[MNemo]

Hallo,

der dir das Erstellen von Tausenden neuen unterschiedlich großen Segmenten erspart.

Warum sollten den "tausende" Segmente für ein paar Compiler-Instanzen nötig sein?

Ich denke der Linux-Kernel besteht aus mehr als nur ein paar Dateien. Und ein ich weiß zwar nicht genau welche Prozesse alle beim Kompilieren einer Datei gestartet werden, aber des sind AFAIK mehr als einer. Die beim Parsen der Datei dann feststellen, dass noch zusätzlich ein paar header Dateien nachgeladen werden müssen, so dass das Daten Segment wachsen muss, was zu Problemen führt wenn der darauf folgende Adressraum an eine der Parallel laufenden Compiler Instanzen vergeben wurde.

Ansonsten hast Du natürlich recht das fragmentierte Segmente gerade dann entstehen wenn Performance benötigt wird. Aber das Problem trifft doch Flat-Memory-Systeme genau so. Speicher wird üblicherweise dann angefordert wenn er auch benötigt wird und dann muss das OS dem so schnell als möglich nachkommen. In einem Flat-Memory-System musst Du ein Mapping anlegen (und dafür im Zweifelsfall ne Menge einzelner physischer Pages aus dem wahrscheinlich ziemlich zerklüfteten physischen Speicher zusammensuchen), das kann man kurzsichtig etwas beschleunigen indem nur der virtuelle Adressraum belegt wird und das eigentliche Mapping dann später über unzählige und teure (daher kurzsichtig) Page-Faults nachholt. Wenn ich ein Segment anlegen muss kann ich prüfen ob das sofort in einem Stück geht (wäre der Optimalfall) oder ob es fragmentiert entstehen muss und dann muss ich ebenso ein Mapping anlegen und hab dabei auch die selben kurzsichtigen Beschleunigungsoptionen. Damit der Optimalfall möglichst oft eintritt kann ich im Hintergrund prophylaktisch defragmentieren aber das lohnt sich IMHO nur wenn der lineare Speicher auch bereits nennenswert ausgelastet oder stark zerklüftet ist (und das ist wohl nur selten).

Eine freie Page finde ich mit niedrigem konstanten Aufwand. Und ein Mapping anzulegen ist gegen das Defragmentieren trivial.

Code und Datenbereich sind das worauf es ankommt.

Und was ist mit dem Heap, der ist in klassischen Flat-Memory-System auch oft ziemlich zerklüftet.

Was willst du mir damit sagen?
Den Heap kann und braucht man auch nicht Defragmentieren. Und wenige Byte große Löscher im Heap stören den Einsatz von großen Pages auch nicht.

[…] aber es gibt trotzdem viele Situationen wo man mal tiefe Call-Trees erzeugt […]

Z. B. ein Backtrack-Algorithmus mit hoher Rekursion tiefe? Da wird nur relativ selten zwischen unterster und oberster Ebene wechseln. Von daher ist der Stackbereich auf dem auch gearbeitet wird immer noch nicht so groß.

Und das mit der passende Ausrichtung lässt sich ja machen.

Und wie? Mit defragmentieren? Welches Flat-Memory-OS macht das denn?

Das wohl bekannteste wäre da wohl Linux. Wie das bei den NT-Kerneln aus sieht weiß ich nicht.
[edit]Das dachte ich zumindest mal gelesen zu haben. Aber ich finde es gerade nicht. Vielleicht hab ich das auch mit KSM(Kernel Samepage Merging) verwechselt.[/edit]

[erik.vikinger]

Hallo,

was zu Problemen führt wenn der darauf folgende Adressraum an eine der Parallel laufenden Compiler Instanzen vergeben wurde.

Ja, dann muss das Segment fragmentiert werden. Aber wo genau ist das Problem? Ein passendes Mapping für den neuen Speicher muss doch ein Flat-Memory-System auch machen. Ich sehe da erstmal keinen relevanten Performance-Unterschied, nur das ich mit den Segmenten prinzipiell die Möglichkeit hab das Paging wieder los zu werden. Das mag in einem Szenario wo mit recht kurzlebigen Prozessen nur so geschmissen wird, kein Vorteil sein (weil es einfach nicht dazu kommt) aber bei längerlebigen Prozessen, die nicht ständig große Mengen an Speicher allozieren oder freigeben, bringt das IMHO schon einen signifikanten Vorteil.

Eine freie Page finde ich mit niedrigem konstanten Aufwand. Und ein Mapping anzulegen ist gegen das Defragmentieren trivial.

Das erste trifft auf mein System doch auch zu und beim zweiten muss ich sagen das mein System im Worst-Case nicht schlechter ist als ein Flat-Memory-System aber im Best-Case eben deutlich schneller.

Den Heap kann und braucht man auch nicht Defragmentieren. Und wenige Byte große Löscher im Heap stören den Einsatz von großen Pages auch nicht.

Das man den Heap nicht defragmentieren kann ist mir klar (schließlich gibt es ja Pointer die da hin zeigen) aber es können durchaus große Löcher im Heap entstehen deren Pages dann manchmal frei gegeben werden um eben weniger Speicher zu verbrauchen und diese Löcher können dann dem Einsatz großer Pages schon mal im Weg sein.

.... Von daher ist der Stackbereich auf dem auch gearbeitet wird immer noch nicht so groß.

Stimmt.

Und wie? Mit defragmentieren? Welches Flat-Memory-OS macht das denn?

Das wohl bekannteste wäre da wohl Linux. Wie das bei den NT-Kerneln aus sieht weiß ich nicht.

Echt, das wusste ich noch nicht. Dann unterscheidet sich von den grundlegenden Fähigkeiten her mein OS ja gar nicht so sehr von Linux außer eben in dem Punkt das wenn mein OS diese Fähigkeiten anwendet zum Schluss das Paging abgeschaltet werden kann.

Bei was für einer Gelegenheit defragmentiert den Linux? Gibt es da einen Idle-Thread im Kernel?


Grüße
Erik

[MNemo]

Ok. Das du letzt endlich doch Paging verwendest hab ich jetzt nicht beachtet.

Das man den Heap nicht defragmentieren kann ist mir klar (schließlich gibt es ja Pointer die da hin zeigen) aber es können durchaus große Löcher im Heap entstehen deren Pages dann manchmal frei gegeben werden um eben weniger Speicher zu verbrauchen und diese Löcher können dann dem Einsatz großer Pages schon mal im Weg sein.

Ich gehe halt von weniger Sozialen Anwendungen aus, die siech nicht die mühe machen löscher im Heap frei zu geben.

Und wie? Mit defragmentieren? Welches Flat-Memory-OS macht das denn?

Das wohl bekannteste wäre da wohl Linux. Wie das bei den NT-Kerneln aus sieht weiß ich nicht.

Echt, das wusste ich noch nicht. Dann unterscheidet sich von den grundlegenden Fähigkeiten her mein OS ja gar nicht so sehr von Linux außer eben in dem Punkt das wenn mein OS diese Fähigkeiten anwendet zum Schluss das Paging abgeschaltet werden kann.

Bei was für einer Gelegenheit defragmentiert den Linux? Gibt es da einen Idle-Thread im Kernel?

Siehe hier mein Edit. Scheinbar hab ich mich da geirrt.

[kevin]

Das wohl bekannteste wäre da wohl Linux. Wie das bei den NT-Kerneln aus sieht weiß ich nicht.
[edit]Das dachte ich zumindest mal gelesen zu haben. Aber ich finde es gerade nicht. Vielleicht hab ich das auch mit KSM(Kernel Samepage Merging) verwechselt.[/edit]

Hm, eventuell im Zusammenhang mit Transparent Huge Pages?

[MNemo]

Das wohl bekannteste wäre da wohl Linux. Wie das bei den NT-Kerneln aus sieht weiß ich nicht.
[edit]Das dachte ich zumindest mal gelesen zu haben. Aber ich finde es gerade nicht. Vielleicht hab ich das auch mit KSM(Kernel Samepage Merging) verwechselt.[/edit]

Hm, eventuell im Zusammenhang mit Transparent Huge Pages?

Ja, das entspricht zumindest dem was ich im Hinterkopf hatte.

[erik.vikinger]

Hallo,

Ok. Das du letzt endlich doch Paging verwendest hab ich jetzt nicht beachtet.

Ich muss, ansonsten müsste ich das Verschieben/Defragmentieren von Segmenten als atomare Aktion ausführen und dafür eventuell auch noch große Teile des System lahm legen. Das Paging ist ein essentieller Bestandteil meines Konzepts, eben weil ich damit ne Menge Speichermagie machen kann und weil ich es auch zum Swappen benötige.

Ich gehe halt von weniger Sozialen Anwendungen aus, die siech nicht die mühe machen löscher im Heap frei zu geben.

Das würde aber bedeuten das Du weniger soziale Programme auch noch mit zusätzlicher Performance belohnst. Das klingt irgendwie sehr nach der realen Welt da draußen.
In meinem OS soll das anders sein. Da werden Programme die riesige aber nur dünn benutze Segmente haben bei Speicherknappheit bestraft in dem die unbenutzten Bereiche ausgelagert werden und dafür bei diesem Segment das Paging aktiv sein muss. Ein Segment das nicht vollständig im Speicher ist ist also auch immer fragmentiert.

Siehe hier mein Edit. Scheinbar hab ich mich da geirrt.

Dein Edit kam wohl kurz nachdem ich auf den "Zitieren"-Button geklickt hatte, schade dass das Forum da nicht warnt so wie bei neuen Beiträgen.
Aber ohne das Defragmentieren von physischen Pages kann ein Flat-Memory-System eigentlich kaum große Pages anbieten, also ist es IMHO logisch das Linux (und wohl auch Windows) das kann.

aber i386 ist mir krank genug und ich habe es noch nicht einmal annähernd durchgespielt.

Mir ist dieser Satz noch mal durch den Kopf gegangen und ich muss sagen das er ein Widerspruch in sich selbst ist. Wie kann man etwas (als krank) beurteilen das man nicht "einmal annähernd durchgespielt" hat?
Da wird doch das eigentliche Problem offensichtlich: die Leute haben eine vorgefasste Meinung (die basiert zumeist auf Gerüchten und ein paar unangenehmen Erinnerungen mit etwas völlig anderem aus grauer Vorzeit das zufällig den selben Namen hat) und fertig.
Sorry, wenn ich da jetzt jemanden auf den Schlips getreten bin aber das musste ich mal loswerden.


Grüße
Erik

[kevin]

aber i386 ist mir krank genug und ich habe es noch nicht einmal annähernd durchgespielt.

Mir ist dieser Satz noch mal durch den Kopf gegangen und ich muss sagen das er ein Widerspruch in sich selbst ist.

Musst du eigentlich immer jedes Wort auf die Goldwaage legen? Das ist mit der Zeit anstrengend.

Wie kann man etwas (als krank) beurteilen das man nicht "einmal annähernd durchgespielt" hat?
Da wird doch das eigentliche Problem offensichtlich: die Leute haben eine vorgefasste Meinung (die basiert zumeist auf Gerüchten und ein paar unangenehmen Erinnerungen mit etwas völlig anderem aus grauer Vorzeit das zufällig den selben Namen hat) und fertig.

Dass man etwas noch nicht in die Praxis umgesetzt ("durchgespielt") hat, heißt doch nicht, dass man automatisch keine Ahnung davon hat? Ja, mir fehlt vielleicht die praktische Erfahrung, aber deswegen ist meine Meinung trotzdem nicht auf Gerüchten und unangenehmen Erinnerungen, sondern auf der offiziellen Dokumentation des Prozessors basiert.

Wenn du deine hohen Ansprüche behalten willst, solltest du ab sofort nicht mehr über deine Plattform reden (oder hast du mittlerweile eine Maschine physisch vor dir stehen?) und jede Diskussion mit Svenska sofort beenden (wenn ich mich nicht täusche, gehört der hier nämlich zur Fraktion der reiner Theoretiker). Spekulationen über die Kaputtheit von etwas, das du selbst noch nicht implementiert hast, gehören dann selbstverständlich auch der Vergangenheit an.

Stimmst du mir zu, dass deine Aussage Blödsinn war?

[Svenska]

und jede Diskussion mit Svenska sofort beenden (wenn ich mich nicht täusche, gehört der hier nämlich zur Fraktion der reiner Theoretiker).

Korrekt. Schlimm?

[erik.vikinger]

Hallo,

Musst du eigentlich immer jedes Wort auf die Goldwaage legen? Das ist mit der Zeit anstrengend.

Naja, da ist so eine meiner Schwächen. Eigentlich war das auch nicht konkret an Dich gerichtet, ich hab beim Zitat extra absichtlich das Referer weg gelassen. Es ging mir um die generelle Einstellung vieler Leute zur Segmentierung die oft durchscheint.

Dass man etwas noch nicht in die Praxis umgesetzt ("durchgespielt") hat, heißt doch nicht, dass man automatisch keine Ahnung davon hat?

Das hab ich auch nicht behauptet, es geht mir um die Abwertung (als krank) die nicht rational begründet wurde.

Ja, mir fehlt vielleicht die praktische Erfahrung, aber deswegen ist meine Meinung trotzdem nicht auf Gerüchten und unangenehmen Erinnerungen, sondern auf der offiziellen Dokumentation des Prozessors basiert.

Das ist auch völlig richtig, aber Du hast da IMHO keine Meinung sondern eine (negative) Wertung ausgedrückt (sorry, da ist wieder die Goldwaage).

Wenn du deine hohen Ansprüche behalten willst

Was für Ansprüche eigentlich? Das ich es nicht mag wenn die Segmentierung so unbegründet abgewertet wird?
Wenn dann auch noch im selben Satz erklärt wird das diese Wertung keinerlei Grundlage hat empfinde ich persönlich das als unpassend.

solltest du ab sofort nicht mehr über deine Plattform reden

Ist das Dein Wunsch?

Fraktion der reiner Theoretiker

Was ist so schlimm an Theoretikern? Ohne die hätte heute keiner von uns einen Computer vor der Nase.

Spekulationen über die Kaputtheit von etwas, das du selbst noch nicht implementiert hast

Aber ich hab Segmentierung und auch Paging bereits mehrfach ausgiebig benutzt. Hat hier schon mal jemand selber Paging implementiert? Muss man dann auch mal ein Auto implementiert haben um sich überhaupt über das Fahrverhalten eines existierenden Autos beschweren zu dürfen?

Stimmst du mir zu, dass deine Aussage Blödsinn war?

Nein, meine Aussage war vielleicht nicht perfekt formuliert und sicher auch etwas frustgeladen aber ich stehe dazu! Wenn ich was negatives über Paging gesagt hab dann hab ich das auch immer rational begründet und nicht einfach inhaltslose Attribute wie "krank" oder "kaputt" benutzt.


Grüße
Erik