Tetsuo Handa
from-****@i-lov*****
2009年 5月 22日 (金) 17:47:55 JST
熊猫です。 Hiroshi Shinji さんは書きました： > これって、ポリシーが削除済みかどうかのマーキングをするための領域分、 > 増加したということでしょうか？ いいえ、削除済みかどうかのマーキングするための領域は既にあります。 メモリ消費の増加は、主に以下にあげる６項目が原因です。 （１）文字列を解放可能にするために ページ単位（多くの環境では４０９６バイト）でメモリを割り当て、可能な限り多くの 文字列を保持する。 ↓ 文字列毎にその文字列の長さ以上（３２以上の２のべき乗の長さ）のメモリを 割り当て、その文字列だけを保持する。 という仕様変更により最大で約５０％のメモリ消費増。（メモリ管理機構の仕様により 文字列の長さピッタリのバイト数を割り当てることはできないため、例えば長さ１６ バイトの文字列を保持するためには３２バイト、長さ６５バイトの文字列を保持する ためには１２８バイトのメモリが割り当てられてしまいます。） （２）文字列を解放可能にするために 文字列のリストを単方向リンクリストで管理する。 ↓ 文字列のリストを双方向リンクリストで管理する。 という仕様変更により文字列１個につき sizeof(struct list_head *) （３２ビット 環境では４バイト）のメモリ消費増。 （３）文字列を解放可能にするために 文字列に対してリファレンスカウンタを使用しない。 ↓ 文字列に対してリファレンスカウンタを使用する。 という仕様変更により文字列１個につき sizeof(atomic_t) （３２ビット環境では ４バイト）のメモリ消費増。 （４）リストから要素を削除できるようにするために リストの要素を単方向リンクリストで管理する。 ↓ リストの要素を双方向リンクリストで管理する。 という仕様変更により要素１個につき sizeof(struct list_head *) （３２ビット環境 では４バイト）のメモリ消費増。 （５）リストから要素を削除できるようにするために リストの要素に対してリファレンスカウンタを使用しない。 ↓ リストの要素に対してリファレンスカウンタを使用する。 という仕様変更により要素１個につき sizeof(atomic_t) （３２ビット環境では ４バイト）のメモリ消費増。 （６）リストの要素のサイズを if 節の有無に依存させないようにするために アクセス許可に if 節がある場合だけメモリ領域を割り当てる。 ↓ アクセス許可に if 節が無くてもメモリ領域を割り当てる。 という仕様変更により要素１個につき sizeof(atomic_t) （３２ビット環境では ４バイト）のメモリ消費増。 この内、（２）（４）については（ＧＣとは無関係ですが） TOMOYO 2.2.0 では既に 採用されています。 TOMOYO 2.x でＧＣを搭載するために（１）（３）（５）が必要に なります。 今後 TOMOYO 1.x の機能を 2.x に移植していく上では、 1.x と 2.x が同様の構造に なっているほうが移植しやすいでしょうから、 TOMOYO 2.x がＧＣを搭載することに なるのであれば、この機会に TOMOYO 1.x も書き換えるのもありかと思います。 ＧＣが搭載されると、学習モードでの動作中にバックアッププログラムなどによりＭＢ 単位のメモリが割り当てられてしまった場合でも、システムを再起動させることなく 不要なメモリを解放できるようになります。 > オプション指定してGCを有効／無効にすることはできるのでしょうか？ カーネルコンフィグでの指定はできなくは無いでしょうが、 ソースコードが #if の嵐になる恐れがあります。
TOMOYO
Fork