Autor Thema: memalloc  (Gelesen 5476 mal)

Sapphire

  • Beiträge: 16
    • Profil anzeigen
Gespeichert
« am: 14. June 2008, 11:57 »
Hallo erstmal.

Ich sitze grad an einer memalloc Funktion. Habe mir Gedanken gemacht und habe jetzt mal ein paar Fragen dazu.

1) Ich habe mir Überlegt das ich am Anfang jeder neu angeforderten Page eine BitMap platziere. Jedes Bit soll 2 Byte darstellen. So habe ich zwar 1 Byte verschwendet bei Speicherbereichen die ungerade sind, aber es geht pro Page nur 1/16 (256 Bytes) des Speichers drauf.

Frage: Ist es Sinvoll 2 Bytes pro Bit zu benutzen oder sollte ich lieber 1 Byte nehmen, wodurch dann aber schon 1/8 (512 Bytes) für die BitMap belegt sind.
Oder ist das ein ganz falscher Ansatz und es geht platzsparender?

2) memalloc muss sich ja auch die breiets angeforderten Pages speichern. Ich habe mir überlegt das man es dafür z.B. eine Page anfordert und dort erstmal nur die Startadressen der Pages speichern könnte.

Frage: Aber wie soll man dann verfahren wenn die Page voll ist? Wie speichere die nächsten Startadressen ?
Und viel wichtiger: Ist das wiederrum sinnvoll? Oder gibt es auch hier eine bessere / platzsparendere Möglichkeit.

Und noch eine Frage die erstmal nichts mit memalloc zu tuen hat:
3)Was kommt nach dem Speichermanager auf Page basis ?
Erst der Virtual Memory und dann eine Funktion alla memalloc oder umgekehrt.

Ich hoffe ihr könnt mir helfen, hatte bisher nur einen simplen Speichermanager der verkette Listen benutzt hat und hab mir daher um sowas keine gedanken gemacht.


Termite

  • Beiträge: 239
    • Profil anzeigen
Gespeichert
« Antwort #1 am: 14. June 2008, 15:54 »
moin

Ich hab das bisher so verstanden, das der Speicher den malloc verwaltet in einer art verkettten liste verwaltet wird. Vor jedem Speicherbereich ist eine kleine Datenstrucktur die Auskunft über grösse des Speicherbereiches, den vorherigen und nachfolgenden Datensatz auskunft gibt. Insgesamt werden 2 listen verwaltet, die des freien speichers, und die des belegten speichers. wird speicher angefordert, wird eine neue datenstruktur angelegt, oder eine aus der liste des Freienspeichers verwendet, und in der Liste des belegten speichers eingetragen. Entsprechend wird dann aus der liste des Freispeichers der bereich entfernt. Wird der speicher wieder freigegeben, wandert der eintrag in die liste des Freien speichers.

deine map hat ein Problem, wenn mehr Speicher angefordert wird, als in einer page platz hat, geht das nicht die verwaltungsstruktur liegt dann irgendwo dazwischen. Du limitierst damit den maximal anzufordernden speicher auf page size - verwaltungsdaten.

Sapphire

  • Beiträge: 16
    • Profil anzeigen
Gespeichert
« Antwort #2 am: 14. June 2008, 16:09 »
Ok. Danke werde es jetzt so machen.

Hätte ich eig auch drauf kommen müssen, manchmal denkt man viel zu kompliziert.  :roll:

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #3 am: 14. June 2008, 16:23 »
Man braucht eigentlich keine Liste der belegten Speicherbereiche, da die belegten Bereich ja vom Programm, welches diese alloziert, verwaltet wird. Man braucht aber einen kleinen Bereich vor den allozierten Speicherbereichen, der die Größe des Speicherbeichs angibt. Kannst dir ja mal die Implementation in pdclib anschauen.
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #4 am: 17. June 2008, 13:16 »
Warum besteht ihr eigentlich alle darauf, daß die Informationen vor dem reservierten Bereich liegen müssen? Sie müssen halt da sein, ob direkt vor dem reservierten Bereich, direkt danach oder ganz woanders. Je nach Variante erhöht oder verringert man halt die Chance, sich bei einem Buffer Overflow alles zu zerschießen. Ob man das haben will oder nicht, dürfte eine Frage der eigenen Philosophie sein. ;)
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #5 am: 17. June 2008, 13:23 »
Warum besteht ihr eigentlich alle darauf, daß die Informationen vor dem reservierten Bereich liegen müssen?
Wie groß war nochmal der reservierte Bereich? :wink: Richtig, dass steht ja bei (Bereich + Größe), dazu braucht natürlich nur die Größe! Da schau ich doch gleich bei (Bereich + Größe) nach. Doch w8, da braucht ich ja die Größe für :-D 8-) :mrgreen:
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

kevin

  • Administrator
  • Beiträge: 2 767
    • Profil anzeigen
Gespeichert
« Antwort #6 am: 17. June 2008, 13:26 »
Okay, danach ist Schwachsinn, sehe ich ein. ;) Aber die Verwaltungsstrukturen komplett separat zu haben, ginge trotzdem immer noch.
Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end.

bluecode

  • Beiträge: 1 391
    • Profil anzeigen
    • lightOS
Gespeichert
« Antwort #7 am: 17. June 2008, 13:32 »
Ja, man kann Dinge natürlich langsamer und platzaufwendiger machen als notwendig, aber ob das Sinn macht, bezweifle ich doch ganz stark. :wink:
lightOS
"Überlegen sie mal 'nen Augenblick, dann lösen sich die ganzen Widersprüche auf. Die Wut wird noch größer, aber die intellektuelle Verwirrung lässt nach.", Georg Schramm

 

Einloggen