linuxメモリ割り当てslubのいくつかの疑問
詳細
SLUBに詳しくない学生は先にスキップすることができて、関連するものは比較的に細かいです.
簡単に言えばSLUBの仕組みはN(CPU数)個kmem_cache_cpuとkmem_cache_Node組成.そのうちkmem_cache_cpuの目的は、CPUヒットキャッシュを技術的に向上させ、同じページに汚れたメモリが1つも表示されない(すなわち、異なる場合に複数のCPUに保持される)ことである.私はこの実現メカニズムをWINDOWSの下で手作業で実現し、複数のkmemを開いた.cache_cpuで問題が発生しました.
1.対象を解放する際、現在のkmem_であるか否かを判断するcache_cpuページの場所
2.もしそうであれば、直接挿入
3.そうでない場合は、隣接ノードに解放
単一kmemならcache_cpuは間違いなく大丈夫ですが、複数kmem_cache_cpuの下では、そのうちの1つをkmem_cache_cpuがすでに持っているページは隣接ノードに解放されます.例を挙げます.
ページアドレスが0-9であると仮定すると、
kmem_cache_cpu 1,Aページを持ち,空きはA 0-A 5
kmem_cache_cpu 2、Bページを持って、
kmem_の番になるとcache_cpu 2が実行されると、AページのアドレスA 6が解放され、プログラムがBページでないことを検出すると、隣接ノードに直接解放される.では、このときAページは2つにカットされ、共通の隣接ノードにあります.このときは逆にメモリの汚れが増しています.コードをよく見ると、ソースコードには次の項目があります.
struct page*pageに気づく;もう?以前は無視していました.そして真実は割り当てられた関数の中にあり、
freelistが無効な場合、pageページのアドレスが複数回クエリーされます.
2011年1月15日増加
細かく見てみると、やはりこの場所にバグがあるような気がします.
リリースには2つのステップがあります
1)ローカルPAGEを歩く
2)NODEノード
申請が複雑だ
1)ローカルfreelistを歩く
2)このページを歩く
3)隣のノードを歩く
4)システム走行
解放すべきように見えることをしました
1)pageとfreelistが空の場合はdeactivate_slab();
deactivate_slabには互換性のある判断がたくさんあり、一つ一つ捨てなければならない.ソースを読むのが一番つらいのはこの点です.
値page->inuseが使用されます.この値はおかしいです.kmemを指しています.cache_cpu現在+使用中のオブジェクト、解放された場合
マイナス1を行うので、彼の++は見えません.
1)page->inuseが0より大きく、freelistに値がある場合は、隣接者に追加します.この推定は互換性のあるコードで、前の判断freelistは空ではありません.
2)逆に隣のチェーンテーブルに追加します.
3)現在の隣接チェーンテーブルがいっぱいであれば、解除する
2)freelistが空の場合、pageが空でない場合、他のkmem_cache_cpuがオブジェクトを解放するとload_freelist:
疑問1:隣接チェーンテーブルに追加することと、隣接チェーンテーブルに追加する衝突を解放することです.条件的には両方ともpage->freelistが空加入しているかどうかに依存していますがdeactivate_slabが隣接ノードに追加された後、page->freelistは処理されませんでしたが、オブジェクトが解放された場合、重複した追加が発生しますか?
この疑問は私が間違っていたことです.page->inuse==0であれば、オブジェクトが解放されたことを示し、再解放はトリガーされません.
疑問2:複数kmem_でcache_cpuの場合、解放された要素はすべて共通の隣人ページに配置され、他のkmem_cache_cpuは直接取り、これにより2つの異なるkmemをもたらす.cache_cpuは同じページを共有しており,これは中キャッシュヒットの機能に反している.
SLUBに詳しくない学生は先にスキップすることができて、関連するものは比較的に細かいです.
簡単に言えばSLUBの仕組みはN(CPU数)個kmem_cache_cpuとkmem_cache_Node組成.そのうちkmem_cache_cpuの目的は、CPUヒットキャッシュを技術的に向上させ、同じページに汚れたメモリが1つも表示されない(すなわち、異なる場合に複数のCPUに保持される)ことである.私はこの実現メカニズムをWINDOWSの下で手作業で実現し、複数のkmemを開いた.cache_cpuで問題が発生しました.
1.対象を解放する際、現在のkmem_であるか否かを判断するcache_cpuページの場所
2.もしそうであれば、直接挿入
3.そうでない場合は、隣接ノードに解放
単一kmemならcache_cpuは間違いなく大丈夫ですが、複数kmem_cache_cpuの下では、そのうちの1つをkmem_cache_cpuがすでに持っているページは隣接ノードに解放されます.例を挙げます.
ページアドレスが0-9であると仮定すると、
kmem_cache_cpu 1,Aページを持ち,空きはA 0-A 5
kmem_cache_cpu 2、Bページを持って、
kmem_の番になるとcache_cpu 2が実行されると、AページのアドレスA 6が解放され、プログラムがBページでないことを検出すると、隣接ノードに直接解放される.では、このときAページは2つにカットされ、共通の隣接ノードにあります.このときは逆にメモリの汚れが増しています.コードをよく見ると、ソースコードには次の項目があります.
struct kmem_cache_cpu {
void **freelist; /* Pointer to first free per cpu object */
struct page *page; /* The slab from which we are allocating */
int node; /* The node of the page (or -1 for debug) */
unsigned int offset; /* Freepointer offset (in word units) */
unsigned int objsize; /* Size of an object (from kmem_cache) */
#ifdef CONFIG_SLUB_STATS
unsigned stat[NR_SLUB_STAT_ITEMS];
#endif
};struct page*pageに気づく;もう?以前は無視していました.そして真実は割り当てられた関数の中にあり、
freelistが無効な場合、pageページのアドレスが複数回クエリーされます.
2011年1月15日増加
細かく見てみると、やはりこの場所にバグがあるような気がします.
リリースには2つのステップがあります
1)ローカルPAGEを歩く
2)NODEノード
申請が複雑だ
1)ローカルfreelistを歩く
2)このページを歩く
3)隣のノードを歩く
4)システム走行
解放すべきように見えることをしました
1)pageとfreelistが空の場合はdeactivate_slab();
deactivate_slabには互換性のある判断がたくさんあり、一つ一つ捨てなければならない.ソースを読むのが一番つらいのはこの点です.
値page->inuseが使用されます.この値はおかしいです.kmemを指しています.cache_cpu現在+使用中のオブジェクト、解放された場合
マイナス1を行うので、彼の++は見えません.
1)page->inuseが0より大きく、freelistに値がある場合は、隣接者に追加します.この推定は互換性のあるコードで、前の判断freelistは空ではありません.
2)逆に隣のチェーンテーブルに追加します.
3)現在の隣接チェーンテーブルがいっぱいであれば、解除する
2)freelistが空の場合、pageが空でない場合、他のkmem_cache_cpuがオブジェクトを解放するとload_freelist:
疑問1:隣接チェーンテーブルに追加することと、隣接チェーンテーブルに追加する衝突を解放することです.条件的には両方ともpage->freelistが空加入しているかどうかに依存していますがdeactivate_slabが隣接ノードに追加された後、page->freelistは処理されませんでしたが、オブジェクトが解放された場合、重複した追加が発生しますか?
この疑問は私が間違っていたことです.page->inuse==0であれば、オブジェクトが解放されたことを示し、再解放はトリガーされません.
疑問2:複数kmem_でcache_cpuの場合、解放された要素はすべて共通の隣人ページに配置され、他のkmem_cache_cpuは直接取り、これにより2つの異なるkmemをもたらす.cache_cpuは同じページを共有しており,これは中キャッシュヒットの機能に反している.