Zur Realisierung der beiden Speicherpools wurde die LMM4.3 Bibliothek aus dem OSKit verwendet, die es erlaubt, Pools mit einer oder mehreren Regionen zu verwalten.
Im Falle des vmem Pools wird also initial eine Region angelegt und mit einem angeforderten Dataspace für Hauptspeicher assoziiert. Die Abbildung Adreßraum-Region - Dataspace wird nach [L$^+$99] von einer dedizierten Instanz -- region mapper -- innerhalb der L4-Task durchgeführt. Der Dataspace kann zu jedem Zeitpunkt ,,Lücken`` enthalten, d.h. Seitenfehler beim Zugriff auf Adressen innerhalb der vmem Region sind erlaubt und werden vom region mapper aufgelöst.
Der kmem Pool enthält zu Beginn auch nur eine Region, deren Dataspace aber gepinnten und physisch fortlaufenden Speicher enthält. Stellt die LMM Bibliothek bei einer Allokation fest, daß nicht genügend Speicher im Pool ist, wird eine sog. morecore() Funktion aufgerufen. Diese kann nun neue Bereiche in den Pool einfügen. In unserem Fall wird eine neue Region mit assoziertem Dataspace angelegt und dem Pool zugeführt.
Eine neue Region muß angelegt werden, damit der LMM nicht aufgrund virtuell fortlaufender Adressen Bereiche allokiert, die Dataspace-Grenzen überschneiden. Dann wäre die physically contiguous Eigenschaft nicht in jedem Fall garantiert.
Neben dem kmem LMM Pool wird noch eine Tabelle geführt, die je Dataspace-Anfangsadresse eine Abbildung der virtuellen auf die physische Adresse verwaltet. Die physischen Adressen der gepinnten Speicherbereiche können beim dataspace manager erfragt werden, was auch beim Anlegen der neuen LMM Region getan wird.
Die Linux-Funktionen virt_to_phys() und phys_to_virt() arbeiten nun mit dieser Tabelle.