21
OS-Design / SLAB-Allocator als Basis fuer kmalloc?
« am: 18. May 2011, 21:52 »
Nabend zusammen,
ich habe jetzt einen fertigen SLAB-Allocator, der stark auf parallelen Zugriff durch feingranulares Locking optimiert ist. Nun wollte ich mir kmalloc schreiben und habe mir ueberlegt, ob es nicht sinnvoll waere kmalloc nur als eine Art Wrapper zu verwenden, der anhand der Groessen entscheidet aus welchem SLAB der Speicher geholt werden soll. Macht sowas sinn? Das erhoeht natuerlich den Verwaltungsoverhead, da ich mehrere Slabs fuer ein kmalloc brauche. Ausserdem erlaubt mein Kernel Speicherallokationen aus bestimmten bereichen (low- oder highmem). Ausserdem wird noch zwischen normalem und boot Speicher unterschieden. Nach dem Bootvorgang wird der gesamte boot Speicher freigegeben, damit der Kernel so wenig Speicher wie moeglich verschwendet. Somit muesste ich auf jeden Fall drei SLABS anlegen, wobei das noch nicht reichen duerfte. Ansonsten muss jeder SLAB grosse Bloecke verteilen, die zu einen starken inneren Fragmentierung fuehren. Also brauchte ich 3 * x SLABS.
Ist das noch praktikabel?
Habe auch lockless Allokation-Algorithmen gefunden, die sind aber vermutlich nicht viel optimaler.
Gruss,
rizor
ich habe jetzt einen fertigen SLAB-Allocator, der stark auf parallelen Zugriff durch feingranulares Locking optimiert ist. Nun wollte ich mir kmalloc schreiben und habe mir ueberlegt, ob es nicht sinnvoll waere kmalloc nur als eine Art Wrapper zu verwenden, der anhand der Groessen entscheidet aus welchem SLAB der Speicher geholt werden soll. Macht sowas sinn? Das erhoeht natuerlich den Verwaltungsoverhead, da ich mehrere Slabs fuer ein kmalloc brauche. Ausserdem erlaubt mein Kernel Speicherallokationen aus bestimmten bereichen (low- oder highmem). Ausserdem wird noch zwischen normalem und boot Speicher unterschieden. Nach dem Bootvorgang wird der gesamte boot Speicher freigegeben, damit der Kernel so wenig Speicher wie moeglich verschwendet. Somit muesste ich auf jeden Fall drei SLABS anlegen, wobei das noch nicht reichen duerfte. Ansonsten muss jeder SLAB grosse Bloecke verteilen, die zu einen starken inneren Fragmentierung fuehren. Also brauchte ich 3 * x SLABS.
Ist das noch praktikabel?
Habe auch lockless Allokation-Algorithmen gefunden, die sind aber vermutlich nicht viel optimaler.
Gruss,
rizor