kmem

Der ,,normale`` Kernspeicher hingegen stellt andere Ansprüche. Wie oben erwähnt, muß für jede virtuelle Adresse eine Abbildung auf eine physische existieren und die Seiten stets im physischen Speicher gehalten -- gepinnt -- werden. Allokationen von Chunks des kmem über Seitengrenzen hinaus müssen korrespondierende, physisch fortlaufende Speicherseiten garantieren -- physically contiguous memory.

Die Lösung im DDE ist in Abb. 3.2 (linke Seite, schraffierte Blöcke) dargestellt. Der Kern-Speicherpool besteht hierbei aus mehreren Dataspaces, die bei Bedarf angefordert und dem Pool zugeführt werden können. Hier erfüllt jeder einzelne Dataspace die Bedingungen an kmem Chunks: gepinnt, fortlaufend und bekannte Adreßabbildung.

Diese Lösung ist vorteilhaft, da die Allokation eines großen, physisch fortlaufenden Speicherbereiches, wenn zum Startzeitpunkt überhaupt möglich, sehr statisch ist. Allokiert man initial nur einen kleinen Bereich und fordert bei Bedarf neue Dataspaces an, ist der ,,Verschnitt`` dieser speziellen Speicherseiten nicht so groß. An dieser Stelle ist in Betracht zu ziehen, daß jeder Treiber-Server diese Bereiche benötigt, eine Verschwendung von Speicher also mehrfach ins Gewicht fällt.

Die physische Anfangsadresse wird bei Anforderung eines Dataspaces beim Manager erfragt und lokal verwaltet, damit bei einer Adreßumsetzung keine IPC nötig wird.

Speicherallokationen mit Seitengranularität (get_pages()) werden ähnlich gehandhabt. So wird eine Allokation auf die Anforderung eines passenden Dataspaces bzw. eine Freigabe auf die Rückgabe dessen abgebildet. Auch für diese Bereiche muß die Adreßabbildung $(v\leftrightarrow{}p)$ geführt werden.