Toshiharu Harada
harad****@gmail*****
2009年 5月 22日 (金) 22:11:36 JST
原田@昨日から札幌です。 2009/5/22 Tetsuo Handa <from-****@i-lov*****>: > 熊猫です。 > > >> メモリ消費の増加は、主に以下にあげる６項目が原因です。 > 書き間違い＋書き忘れがあったので補足します。 > >> （１）文字列を解放可能にするために >> >> ページ単位（多くの環境では４０９６バイト）でメモリを割り当て、可能な限り多くの >> 文字列を保持する。 >> ↓ >> 文字列毎にその文字列の長さ以上（３２以上の２のべき乗の長さ）のメモリを >> 割り当て、その文字列だけを保持する。 >> >> という仕様変更により最大で約５０％のメモリ消費増。（メモリ管理機構の仕様により >> 文字列の長さピッタリのバイト数を割り当てることはできないため、例えば長さ１６ >> バイトの文字列を保持するためには３２バイト、長さ６５バイトの文字列を保持する >> ためには１２８バイトのメモリが割り当てられてしまいます。） > 「最大で約５０％のメモリ消費増」ではなくて、「最大で約５０％のメモリが割り当て > られたけれど使われない状態」ですので、「最大で約１００％のメモリ消費増」です。 > > > （７）リストの要素を解放可能にするために > > ページ単位（多くの環境では４０９６バイト）でメモリを割り当て、可能な限り多くの > 要素を割り当てる。 > ↓ > 要素毎に kmalloc() で割り当てる。 > > という仕様変更により、３２バイト以下の要素は３２バイト、３３バイト〜６４バイト > の要素は６４バイトが必要になります。（（６）による影響は実際には（７）に包含 > されます。） > > たくさん使われる要素に関しては、その要素専用の領域を kmem_cache_alloc() で > 割り当てることにより無駄を減らせます。しかし、数個しか使われない要素に > 関しては、その要素専用の領域を kmem_cache_alloc() で割り当てると無駄が増えて > しまいます。 kmalloc() で割り当てるか、 kmem_cache_alloc() で割り当てるのか > 悩ましいところです。 > > > （１）や（７）を考えると、１要素単位の割り当て／解放ができるようにすることは > すごい無駄が多い気がします。１ページ単位での割り当て／解放ができるようにする > だけに留めておいた方が良いのかもしれません。 > > > >> > オプション指定してGCを有効／無効にすることはできるのでしょうか？ >> カーネルコンフィグでの指定はできなくは無いでしょうが、 >> ソースコードが #if の嵐になる恐れがあります。 > その後、考えてみたところ、 list_for_each() とか down_read(&ccs_policy_lock); > とかをマクロを使ってラッピングしてやれば #if の嵐を避けられるのではないか > という気がしてきました。どのみち、まずはＧＣありの場合でソースコードを作成後、 > カーネルコンフィグ依存の部分をマクロ化することになるでしょう。 意見ですが、GCの有無のような内容を選択できるようにしたり、利用者に 選ばせるのは、ちょっと変な気がします。 > 話は変わりますが、２ｃｈでの議論が盛り上がっているようですね。熊猫の使っている > ＩＰは荒らしの巻き添えにより３／１９を以って永久書き込み規制となったので、 > 熊猫が２ｃｈに降臨することはありません。 個人的には、是非情報提供、議論に参加して欲しいと思います。 書きたくなったらメールしてくれたら代理投稿しますので、遠慮なく。 -- Toshiharu Harada harad****@gmail*****
TOMOYO
Fork