● dlmalloc()のarenaの数について
malloc()を語る上では、メモリフラグメンテーション(と速度とサイズのオーバヘッド)の話が永遠のテーマになる。フラグメンテーションについてはこのへんの記事に詳しい
→ Ruby: mallocでマルチスレッドプログラムのメモリが倍増する理由（翻訳）(https://techracho.bpsinc.jp/hachi8833/2017_12_28/50109)
dlmalloc()で少しでもなにか工夫できないかという場合、arenaの数を調整する方法がある。環境変数類で制御する。例えばこんな感じ。
- mallopt(M_ARENA_MAX, 2);
- mallopt(M_ARENA_TEST, 2);
設定しない場合は(論理)CPU数の8倍(64bitの場合)もしくは2倍(32bitの場合)、詳細は arena.c arena_get2()関数の static size_t narenas_limit あたりへ。
ただ、この narenas_limit を決めるアルゴリズムが少し複雑(というか理解をしづらい)ことになっている。特に、途中(narenas_limitがゼロ以外にかくていした後)から ARENA_MAX や ARENA_TEST を変更してもそれらが反映されないなど。設定したつもりでも反映出来ていなかったという事例につながるので要注意。
一度arenaが増えるとプロセス終了するまで二度と減らないので、なおさら注意が必要。arenaはロック競合した場合に新規に作られるので、たくさんのスレッドがCPUを奪い合うケースで顕著にarena数上限に達しやすくなる。そんな状況ならCPUが効率よく使用されないのは仕方ないにしても、そのせいでユーザプロセスがたくさんarena作りメモリを無駄遣いするというのはつらい。
malloc()初心者はこのへんのシリースからでもどうぞ。
mallocの動作を追いかける(mmap編) - Qiita (https://qiita.com/kaityo256/items/9e78b507940b2292bf79)
malloc()問題は初歩的かつ奥が深い問題なので、いろんな人が議論に参加してくるけど、その割にこういうとこまでつっこんで語ってくれる人が少ないだけに、クズ記事に埋もれてしまうことが多くて情報発掘しづらく、結局ソース読んだほうが早いことも多くて辛い...
● kernel内backtrace解析の方法
とりあえず dump_stack(); 便利すぎる。
古典的なデバッグプリント
- pr_info("[%s:%d] %d %s\n", __FUNCTION__, __LINE__, current->pid, current->comm);
ユーザランドがほしい場合は、強制的にセグらせるとか便利。
- send_sig(SIGABRT, current, 0); // 0 == not group
あまりいい方法がない場合は神頼みコンパイラ頼みで。
- __builtin_return_address(0)
参考記事、
- [Linux][C/C++] backtrace取得方法まとめ (https://qiita.com/koara-local/items/012b917111a96f76d27c)
libSegFault.soは知らなかった
