SLABメモリ管理メカニズムの構造化について混乱しています。
一般的に使用されるデータオブジェクトに固有の「キャッシュ」が複数あるようですが、各キャッシュに複数の「スラブ」が含まれているのはなぜですか?
キャッシュ内の各スラブを区別するものは何ですか?キャッシュをデータオブジェクト自体で埋めてみませんか?なぜこの余分なレイヤーが必要なのですか?
SLABメモリ管理メカニズムの構造化について混乱しています。
一般的に使用されるデータオブジェクトに固有の「キャッシュ」が複数あるようですが、各キャッシュに複数の「スラブ」が含まれているのはなぜですか?
キャッシュ内の各スラブを区別するものは何ですか?キャッシュをデータオブジェクト自体で埋めてみませんか?なぜこの余分なレイヤーが必要なのですか?
スラブアロケータは、同じタイプの多数のオブジェクトの割り当てを容易にするための抽象化レイヤーです。インターフェイスは機能を提供します
struct kmem_cache * kmem_cache_create(const char *name,
size_t size, size_t align, unsigned long flags,
void (*ctor)(void*));
size
この関数は、-バイト長のオブジェクトの割り当てを処理できる新しいスラブアロケーターを作成します。作成が成功すると、関連するへのポインタを取得しますstruct kmem_cache
。この構造は、管理するスラブに関する情報を保持します。
ウィキペディアの説明に示されているように、このような追加レイヤーの目的は、メモリの割り当てが単純で直感的な方法で行われた場合に発生する可能性のあるメモリの断片化の問題を防ぐことです。そのために、次のデータ構造を通じてスラブの概念を導入します。
struct slab {
struct list_head list; /* embedded list structure */
unsigned long colouroff;
void *s_mem; /* first object in the slab */
unsigned int inuse; /* allocated objects in the slab */
kmem_bufctl_t free; /* first free object (if any) */
};
したがって、kmem_cache
オブジェクトは3つのフレーバーで収集されたスラブの3つのリストを保持します。
スラブアロケータを介してオブジェクトを要求すると、部分的なスラブ内で必要なメモリ領域を取得しようとします。取得できない場合は、空のスラブから取得します。
これに関する詳細情報を収集したい場合は、RobertLoveのLinuxカーネル開発をご覧ください。
私はこれに答えるには遅すぎるかもしれませんが、これは他の人にも役立つかもしれません。Linux Virtual Memory Managerを理解することからわかるように、スラブを持つことには3つの大きな利点があります。
The Slab Allocator:Object Caching Kernel memory Allocator(1994)のセクション3.2を参照してください。