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