Glibc malloc internal

31,977 views

Published on

glibc mallocの解説

Video: https://youtu.be/0-vWT-t0UHg

Published in: Technology, Design
1 Comment
121 Likes
Statistics
Notes
No Downloads
Views
Total views
31,977
On SlideShare
0
From Embeds
0
Number of Embeds
1,976
Actions
Shares
0
Downloads
322
Comments
1
Likes
121
Embeds 0
No embeds

No notes for slide

Glibc malloc internal

  1. 1. malloc の旅( glibc 編) kosaki @ぬまづ
  2. 2. 今日は何の話? <ul><li>libc でもっとも良く使われる関数、 malloc と free の実装の解説 </li></ul><ul><li>もっと一般的に言うと、プロセスのアドレス空間のうち、 heap 領域とよばれる、場所を操作する関数の説明 </li></ul><ul><li>解説というと聞こえはいいが、そんな大層なものじゃない </li></ul>
  3. 3. Linux での process address space model kernel stack text mmap data bss heap 矢印はデータ量の増加と ともに、伸びる方向 使用中 使用中 使用中 今日は、ここ、 heap と呼ばれる領域のお話 low high free free free
  4. 4. 古典的 malloc プログラミング言語 C (いわゆる K&R) で紹介された初期の Unix の malloc 実装 使用中 使用中 使用中 free listの head 使用中 ・ free list を使って空きメモリを管理 ・プロセス全体でただ1つの Heap を使う ・ malloc するときに管理領域分だけ多く allocate して先頭に管理領域を付加 ( どこかに管理領域がないと free するときに開放 size がわからない ) ・割り付け strategy は first fit. union header{ struct{ union header* ptr; unsigned size; }s; long alignment; };
  5. 5. malloc のアルゴリズム 使用中 使用中 使用中 free listの head 使用中 このぐらい 欲しい X 足りない 1.まず、 list head から先頭ポインタを get 2.空き領域が十分か調べる ・・・・小さすぎた
  6. 6. malloc のアルゴリズム 使用中 使用中 使用中 free listの head 使用中 X また足りない X このぐらい 欲しい 1.まず、 list head から先頭ポインタを get 2.空き領域が十分か調べる 3.ポインタを list の次の要素に進める 4.また空き領域が十分か調べる うむむ。。また小さい
  7. 7. malloc のアルゴリズム 使用中 使用中 使用中 free listの head 使用中 1.まず、 list head から先頭ポインタを get 2.空き領域が十分か調べる 3.ポインタを list の次の要素に進める 4.また空き領域が十分か調べる 5.また、ポインタを次の要素に進める 6.またまた、空き領域を調べる 今度はあった!! X OK X このぐらい 欲しい
  8. 8. malloc のアルゴリズム 使用中 使用中 使用中 free listの head 使用中 1.まず、 list head から先頭ポインタを get 2.空き領域が十分か調べる 3.ポインタを list の次の要素に進める 4.また空き領域が十分か調べる 5.また、ポインタを次の要素に進める 6.またまた、空き領域を調べる 7.空き領域を2つに分けて、 free list をつなぎなおす 8. list head を更新 今確保した 領域 最後に探索が失敗した場所 (アロケートされたメモリの 1つ前 の要素) を指すように変更
  9. 9. 実は・・・ 使用中 使用中 使用中 free listの head 使用中 実はもう1つ先を探すと、もっといい場所が あったのに・・・ X X このぐらい 欲しい 今確保した 領域
  10. 10. free のアルゴリズム 使用中 使用中 使用中 free listの head 使用中 free したい 領域 1. free list head から最初のポインタをゲット 2.最初の要素の、さらに次のポインタもゲット (next = p->s.ptr) 3. p < bp < next が成立しないので次へ bp p next
  11. 11. free のアルゴリズム 使用中 使用中 使用中 free listの head 使用中 free したい 領域 bp p next 1. free list head から最初のポインタをゲット 2.最初の要素の、さらに次のポインタもゲット (next = p->s.ptr) 3. p < bp < next が成立しないので次へ 4. p を次の要素に進める 5 .次のポインタをゲット 6 . p < bp < next が成立した
  12. 12. free のアルゴリズム 使用中 使用中 使用中 free listの head 使用中 bp p 7 . p と bp は隣接していない (p + p->s.size != bp) ので併合しない next 1. free list head から最初のポインタをゲット 2.最初の要素の、さらに次のポインタもゲット (next = p->s.ptr) 3. p < bp < next が成立しないので次へ 4. p を次の要素に進める 5 .次のポインタをゲット 6 . p < bp < next が成立した 8. bp と p->s.ptr は隣接しているので (bp + bp->s.size == next) 併合 free したい 領域
  13. 13. free のアルゴリズム 使用中 使用中 使用中 free listの head 使用中 bp p 7 . p と bp は隣接していない (p + p->s.size != bp) ので併合しない next 1. free list head から最初のポインタをゲット 2.最初の要素の、さらに次のポインタもゲット (next = p->s.ptr) 3. p < bp < next が成立しないので次へ 4. p を次の要素に進める 5 .次のポインタをゲット 6 . p < bp < next が成立した 8. bp と p->s.ptr は隣接しているので (bp + bp->s.size == next) 併合 9. free list head を今開放した要素を 指すよう動かす
  14. 14. 次に malloc の特殊なケース heap にまったく空きがなくて heap 自体を拡張するケースを 説明します
  15. 15. ヒープ拡張 使用中 free listの head 使用中 このぐらい 欲しい heap は無限ではないのでいつか足りなくなる X 足りない
  16. 16. ヒープ拡張 使用中 free listの head 使用中 このぐらい 欲しい heap は無限ではないのでいつか足りなくなる X 足りない X
  17. 17. ヒープ拡張 使用中 free listの head 使用中 このぐらい 欲しい heap は無限ではないのでいつか足りなくなる X 足りない X X
  18. 18. ヒープ拡張 使用中 free listの head 使用中 このぐらい 欲しい heap は無限ではないのでいつか足りなくなる X X X ptr と free list の head が再び一致 (一周してしまった)
  19. 19. ヒープ拡張 使用中 free listの head 使用中 このぐらい 欲しい heap は無限ではないのでいつか足りなくなる ここで brk システムコールで heap 領域を一気に 伸ばす brk は heap 最後尾アドレスを変更するAPI heap 最後尾 heap 最後尾
  20. 20. ヒープ拡張 使用中 使用中 heap は無限ではないのでいつか足りなくなる heap 最後尾 今確保した 領域 増えた領域を 2 つにわけ、先頭をユーザに返却。 残りを free list につなぐ free listの head
  21. 21. やや脱線
  22. 22. 素朴な brk の実装 <ul><li>0. データセグメントには静的データとスタック </li></ul><ul><li>が入っている </li></ul><ul><li>1. 現在値+増加分で (kernel 内で ) malloc </li></ul><ul><li>2. 新しいメモリにメモリコピー </li></ul><ul><li>3. 古いデータを mfree </li></ul><ul><li>4 スタックを末尾にメモリコピー </li></ul><ul><li>5. スタックと静的データの間をゼロクリア </li></ul>new memory data data stack stack 出典: Lions ’ Commentary on UNIX 増加分 data stack data stack data stack data stack data stack
  23. 23. つまり <ul><li>カーネル brk がくそ遅い </li></ul><ul><li>あんまり brk 呼ばなくてもいいように、ユーザー空間で「なるべく brk しない。するときはガバッと一気に取る」方針でいく </li></ul><ul><li>とかいう価値観で実装されておりまする </li></ul>
  24. 24. さて <ul><li>実は brk も、イマドキの Linux では大幅に高速になっているのだが、それは今回は考えない事にする </li></ul><ul><li>今はbrkが遅いって前提で malloc の高速化を考えていくぜい </li></ul>脱線終わり
  25. 25. K&R malloc のいいところ <ul><li>単純 </li></ul><ul><li>コードサイズが小さい。 (組み込みとかも malloc はいまだにこんな形しとるよ) </li></ul><ul><li>フラグメンテーションが進まない限り malloc は O(1) </li></ul><ul><li>プログラム全体で数十回しか malloc しないような小規模プログラムではとてもうまく動く </li></ul>
  26. 26. K&R malloc のダメなところ <ul><li>小さい malloc が多発すると フラグメンテーションがすぐ進む </li></ul><ul><li>free が O(n) </li></ul><ul><li>brk が呼ばれる状況では一回 freelist を一周する必要がある (リストが数万個もあれば、なにそのキャッシュ・フラッシング・コード状態) </li></ul><ul><li>フラグメンテーションが進むとメモリ効率も急激に悪化 </li></ul>
  27. 27. 時代は変わった・・・ <ul><li>イマドキなプログラミング </li></ul><ul><ul><li>GUI </li></ul></ul><ul><ul><li>スクリプト言語や Java </li></ul></ul><ul><ul><li>C++ プログラミング </li></ul></ul><ul><ul><li>等々 </li></ul></ul><ul><li>は、まさに小さい malloc が連発される </li></ul>
  28. 28. 最大の問題はなんだろう? <ul><li>ここは、とりあえずフラグメンテーションが最大の問題だと仮定しよう </li></ul><ul><li>フラグメンテーションさえ解決すれば </li></ul><ul><ul><li>メモリ使用効率 UP! </li></ul></ul><ul><ul><li>使用メモリ量が減れば、それだけキャッシュに載る確率 UP! </li></ul></ul><ul><ul><li>なんか カコ ( ・∀・ ) イイ ! </li></ul></ul>
  29. 29. とゆーわけで、時代は best fit アロケータなのである
  30. 30. で、 Just Idea に従って 実装してみる
  31. 31. アドレス順をやめて、 サイズ順にソートしてみる 使用中 使用中 使用中 free listの head 使用中 free の時に、隣接要素と併合することが不可能に・・・・ よけいフラグメンテーションが進みました 本末転倒
  32. 32. やっぱり malloc header に メンバを増やすしかない struct malloc_chunk { INTERNAL_SIZE_T prev_size; INTERNAL_SIZE_T size; struct malloc_chunk* fd; struct malloc_chunk* bk; }; 使用中 使用中 使用中 free listの head 使用中 変数名を glibc にあわせたので、だいぶ雰囲気が 変わったけど気にしない address space の prev, next はポインタで 持たずサイズで保持している。
  33. 33. 何が変わったのか <ul><li>良くなったところ </li></ul><ul><ul><li>free が typical で O(n) から O(1) へ </li></ul></ul><ul><ul><li>フラグメンテーションによる空間の無駄が減る </li></ul></ul><ul><li>悪くなったところ </li></ul><ul><ul><li>malloc が typical で O(1) から O(n) へ </li></ul></ul><ul><ul><li>ヘッダサイズが増えて空間効率ダウン </li></ul></ul>
  34. 34. だめだめです むしろ此処からが本題
  35. 35. ヘッダのダイエットが必要です <ul><li>まず、 free list のポインタ、 bk, fd は割り付け済みブロックには必要ない </li></ul><ul><li>これは単純に削ればいい </li></ul><ul><li>アクセス方法には注意 </li></ul>prev_size size fd bk malloc_chunk 構造体にキャストして アクセスするので一見、 fd, bk メンバが あるように見えるが、実はそこは ユーザアプリに使われてしまっているので アクセスするとメモリ破壊 ソースコードからは読み取りにくい・・
  36. 36. ダイエットはつづくよ・・・ <ul><li>よーく考えると </li></ul><ul><li>prev_size メンバは free 時の合併処理のみに必要 </li></ul><ul><li>とゆーことは、 prev が free 状態のときのみ必要 </li></ul><ul><li>prev_size は prev が free の時のみ記録したい </li></ul><ul><li>ちょっとまって </li></ul><ul><li>どうやって、 prev が free 状態か調べればいいんだっけ? (卵と鶏問題) </li></ul>
  37. 37. <ul><li>下位 2bit は絶対0になるよね </li></ul><ul><li>glibc malloc は実際には内部で 8 の倍数に切り上げるから、下位3 bit は 0 </li></ul><ul><li>size メンバは2つのポインタの差を記録しているのだから、当然、同じく下位 3bit が0 </li></ul>32bit なシステムのポインタって・・ 0 31 1 2 ポインタ 0 0
  38. 38. というわけで prev_size size fd bk size fd bk use free free prev_size size use size 1 0 size メンバの再下位 bit を prev が USE 状態かを 記録するビットとして使う (図中の   が最下位ビットを示している) 再下位が0なら prev_size メンバがある。 1 1 free() 関数で chunk_p = (malloc_chunk*)(((char*)ptr) - sizeof(size_t)*2); なんてやってるけど、 size メンバ以外はあるかどうか 分からない 構造体の型とメモリ上のデータ構造がまるで 一致していない香ばしい構造 -> 読みにくさの主原因 ブロック1 ブロック2 ブロック3 ブロック4
  39. 39. 時系列で見ると prev_size size fd bk use free free prev_size size fd bk 0 1 1 prev_size size fd bk use free free prev_size size fd bk 0 1 prev_size size fd bk malloc 1 1 prev_size size fd bk prev_size size fd bk 余分に確保するメモリは 4バイトのみ。 request2size() が req + sizeof( malloc_chunk) ではなく req + sizeof(size_t) なのは ここに原因があった!! malloc 編 malloc ヘッダ malloc ボディ(使用中) malloc ボディ( free ) 当然だけど、 malloc ヘッダから 突き抜けている malloc_chunk メンバはアクセスしたらエライ事になります fd,bk メンバはユーザに使われて しまうので壊される
  40. 40. 時系列で見ると use free 1 1 1 1 prev_size size fd bk prev_size size fd bk use prev_size size fd bk prev_size size fd bk free free 1 1 0 1 prev_size size fd bk prev_size size fd bk use prev_size size fd bk prev_size size fd bk free の時に初めて fd, bk, prev_size メンバが 書き込まれる size メンバ以外は、 malloc 時には確保してなかったのだが どうせ free じゃーん。 あいてるじゃーん。 という訳で勝手に使ってる。 ソース上はとってもメモリ破壊ちっく free free 編 ここで prev_in_use フラグが1に
  41. 41. ダイエットは出来たので <ul><li>ある意味、本日の code reading の最難関部分は突破 (^-^; (他の部分は、ちゃんと C 言語ちっくな C のソースコード (?) なので) </li></ul><ul><li>次は最大の課題。 malloc() が typical で O(n) じゃーん。問題を片付ける </li></ul>
  42. 42. ここでアイデア <ul><li>別に free list で、1つのリストに全部つながなくてもいいよね? </li></ul><ul><li>サイズは絶対8の倍数なんだから、サイズ16用のリスト、サイズ24用のリスト・・・・ ってやったら best fist かつ O(1) じゃね? </li></ul>
  43. 43. small bin 16 24 32 40 504 ・・・ size index 2 63 3 4 5 chunks これで小さいサイズの malloc が /* 8 の倍数に切り上げ */ size = request2size(req); if( size <= 512 ) { bin_index = size/8; chunk = bins[bin_index].bk; unlink(chunk); /* remove freelist */ return chunk + sizeof(size_t)*2; } このぐらい簡単に終わる 構造体とかはたいてい、このぐらいのサイズにおさまるよね? best fit どころか、 just fit アロケータですよ。と 8 8 8 8 8 bin width free list head の配列
  44. 44. さらに改良 <ul><li>512byte over の部分が手付かず </li></ul><ul><li>でも、大きいサイズにも 8byte おきに bin を用意するのは現実的じゃない </li></ul><ul><li>でもリストを複数もつ。 というアイデアは悪くない </li></ul>
  45. 45. large bin 588 652 716 780 ・・・ size index 65 123 66 67 68 64 64 64 64 32K bin width 124 32K 125 250K 126 250k 127 ∞ グラフにするとこんなカンジ bin width bin index bin index が大きくなるにつれ、あつかう block size の幅が指数的に大きくなるように調整 小さいサイズのほうが数が多いので、リストにつながる数を平均化するための施策 大きなサイズ用の リストヘッドも 64 個つくる ・・・ 512 4k ・・・ 750k more
  46. 46. でも <ul><li>どう頑張っても、一番ラストの bin は一杯つながってしまうんだよね </li></ul><ul><li>画像とか扱うと平気で数十 M とか malloc するし・・・・ </li></ul><ul><li>あーあ、 Heap をもう1つ用意できたら でかいメモリを完全に分離できるのに・・ </li></ul>
  47. 47. その為の mmap です
  48. 48. anonymous mmap とは? <ul><li>mmap は、本来ファイルをメモリにマップするシステムコール </li></ul><ul><li>でも fd 引数に “ /dev/zero” を渡すことにより、メモリ確保 API として使用可能 </li></ul><ul><li>この API を使って、 Huge Block( デフォルトで 128K byte 以上 ) は heap からではなく、 mmap で直接 kernel から取得する </li></ul>
  49. 49. またしても size メンバの下位 bit を 0 31 1 2 size 0 0 0 IS_MMAPED PREV_IN_USE 下から2 bit 目を mmap から取得したよーん。 という意味で使うことにする。 この bit が ON なら free list からではなく MMAP で取得 しているので、 free 時に freelist につながずに、 いきなり munmap() する
  50. 50. データ構造図解 使用中 使用中 使用中 使用中 使用中 (huge) 使用中 (huge) bins ※ 1 見やすくするために、リストをつなぐ線の種類を少しずつ変えてある ※ 2 Huge かつ free 状態はありえない。開放と同時に OS に返却するから
  51. 51. この方法の利点 <ul><li>Huge Block も malloc, free ともに O(1) </li></ul><ul><li>フラグメンテーション、むっさ起きにくい </li></ul><ul><li>(リスト管理してないんだから当たり前) </li></ul><ul><li>メモリの無駄が少ない (でっかいメモリは同じサイズで再度 malloc される確率は低いので、すぐさま OS に返却するのは賢い戦略) </li></ul>
  52. 52. ここまでの結果 <ul><li>良くなったところ </li></ul><ul><ul><li>malloc が typical で O(1) </li></ul></ul><ul><ul><li>free が typical で O(1) </li></ul></ul><ul><ul><li>フラグメンテーションがすごく起きにくく </li></ul></ul><ul><ul><li>ヘッダサイズは実質4バイト </li></ul></ul><ul><ul><li>brk が発生するときに、 K&R malloc では freelist を一周する必要があったのが、要求サイズより大きい bin を検索するだけでよくなった。 平均で探索コスト 1/2 </li></ul></ul><ul><li>悪くなったところ </li></ul><ul><ul><li>なんかあったっけ? </li></ul></ul>
  53. 53. でも! それでも! しばしば、 K&R malloc に 負けるんです。これが 実は large size block の malloc – free –malloc – free と 繰り返す割り当てが遅い
  54. 54. K&R free を振り返ってみる 使用中 使用中 使用中 free listの head 使用中 bp p next 9. free list head を今開放した要素を 指すよう動かす 今開放した 要素 ここがポイント
  55. 55. キャッシュと局所参照性 <ul><li>heap メモリーに一番アクセスする確率が高いのは malloc 直後と free 直前である </li></ul><ul><li>free されたばかりのメモリはキャッシュに載ってる確率が高い </li></ul><ul><li>そこから優先してメモリ確保することは malloc 直後のアクセスでキャッシュミスしなくなるということ </li></ul>キャッシュのヒット率重要
  56. 56. バッファの遅延合体 <ul><li>free が呼ばれたときに、すぐに隣と併合& free list につなぐ処理をやめる </li></ul><ul><li>最初にこのアイデアを実装したのは SVR4 らしい ( 最前線 UNIX のカーネル より ) </li></ul><ul><li>malloc – free – malloc – free という非常によくあるアクセスパターンでメモリブロックの分離・併合・分離・併合という無駄な処理が避けられる。 </li></ul><ul><li>かつ、 free された順に時系列にリストにつながっているので、リスト先頭の block をアプリに返せばキャッシュヒット率向上 </li></ul>
  57. 57. バッファの遅延合体 その2 <ul><li>gligc malloc では最低確保サイズが 32 なので bins[0] と bins[1] は使ってない </li></ul><ul><li>bins[1] をこの遅延されてる block をつなげるリストのリストヘッドとして特別な意味で用いる </li></ul><ul><li>ソースコード上は unsorted_chunk と呼ばれているが、ソートしない=時系列順である。 </li></ul><ul><li>リストをたぐって、要求サイズと一致するものを検索 </li></ul><ul><li>要求サイズと一致しないものは、この時点で、隣と併合して実際の free 処理 </li></ul>
  58. 58. マクロな視点で話をすると <ul><li>malloc の呼び出しパターンはたいてい以下のような経過をへる </li></ul><ul><li>アプリ起動時はやたら malloc が呼ばれる。 free はほとんど呼ばれない </li></ul><ul><li>その後、 malloc と free がほぼ交互に呼ばれる定常状態に入る </li></ul><ul><li>GUI の画面遷移のような、なんからの契機で、 free がひたすら呼ばれ、次に malloc がひたすら呼ばれるデータ構造の大転換がおこる </li></ul><ul><li>そしてまた定常状態に・・・・ </li></ul>
  59. 59. malloc の 定常状態とバースト状態 バースト状態 バースト状態 このとき、遅延併合が 裏目に出る。 遅延併合リストに要素が 一杯たまるから メモリ使用量 定常状態 遅延併合は裏目にでることもあるが、いちばんありがちな、 定常状態で高速化されるのでモトがとれる
  60. 60. まだもうちょっとだけ 続くんじゃ
  61. 61. みんな大好きマルチスレッド 猫まっしぐら!
  62. 62. 素朴な lock malloc(size_t sz){ lock(); ptr = internal_malloc(sz); unlock(); return ptr; } ご冗談でしょう。ファインマンさん たんじゅんに、関数全体を mutex で保護してみた
  63. 63. 本当はこうしたい 使用中 使用中 使用中 使用中 使用中 使用中 使用中 使用中 bins 使用中 使用中 使用中 使用中 bins bins スレッド1 スレッド2 スレッド3 スレッド1専用 heap スレッド 2 専用 heap スレッド 3 専用 heap ロックのいらない素敵な世界
  64. 64. それは流石に無理 <ul><li>アプリがいくつスレッドをつくるか事前に知る方法はない </li></ul><ul><li>1つのスレッドが最大どのくらいのメモリを使うのか事前に知る方法はない </li></ul><ul><li>ITRON だと両方ともコンパイル時に決まるのに・・ </li></ul>
  65. 65. そこで以下のように実行時に新しい heap を作っていく
  66. 66. Arena 生成 使用中 使用中 使用中 使用中 bins スレッド1 main_arena main_arena == 今まで説明してきた heap アクセス ロック arena 構造体
  67. 67. 使用中 使用中 使用中 使用中 スレッド1 main_arena アクセス ロック アクセス、しかし、ロックとれず bins arena 構造体 スレッド 2 別のスレッドが malloc を同時に呼ぶと、 ロック取得 (mutex_trylock) に失敗 Arena 生成 スレッド2
  68. 68. Arena 生成 スレッド2 使用中 使用中 使用中 使用中 スレッド1 main_arena アクセス ロック スレッド 2 新しい自分専用 heap を mmap で作成 この altanative heap の仕組みを arena と呼んでいる。 TLS(thread local strage) に自分用 arena を覚えておくので スレッドが増えるか 1M 使い切るかしない限り二度とバッティングしない bins arena 構造体 とってきたメモリの先頭を arena 構造体 ( bin 配列などが入っている構造体)として使う 1M free mmap arena 同士は list でつなげる
  69. 69. Arena 生成 スレッド3 使用中 使用中 使用中 使用中 スレッド1 main_arena スレッド 2 bins arena 構造体 free アクセス スレッド 3 アクセス 次のスレッドも、ロック競合が起きるまでは main_arena を 使い続ける
  70. 70. Arena 生成 スレッド3 使用中 使用中 使用中 使用中 スレッド1 main_arena アクセス ロック スレッド 2 bins arena 構造体 free アクセス スレッド 3 アクセス ロックがぶつかったら・・・・
  71. 71. Arena 生成 スレッド3 使用中 使用中 使用中 使用中 スレッド1 main_arena アクセス ロック スレッド 2 bins arena 構造体 free アクセス スレッド 3 アクセス arena list を、たぐって次々とロック取得をチャレンジ すべて失敗したら、また新しい自分専用 arena を作る。
  72. 72. Arena 生成 スレッド3 使用中 使用中 使用中 使用中 スレッド1 main_arena アクセス ロック スレッド 2 bins arena 構造体 free アクセス スレッド 3 mmap いきなり arena 生成をしないのはスレッド2が すでに終了していたときに、その専用 arena が無駄になるのを防ぐため これにより、スレッド生成直後は色々な arena でロック競合するが そのうちに、 1 スレッド・ 1 アリーナに収束する free
  73. 73. 1スレッド:1 Arena の隠れた利点 <ul><li>SMP マシンでは、別の CPU からアクセスしたメモリは自分 CPU のキャッシュには乗らないのでラストアクセスを単純に管理してはうまくいかない </li></ul><ul><li>しかし、ユーザ空間から自分がどの CPU で動いているのか明に意識するのは無理 (いつのまにか勝手に変わるし) </li></ul><ul><li>そこでカーネルがもつスレッドの CPU affinity スケジューリングに着目して、自分スレッドがアクセスしたデータは自分 CPU でアクセスした確率が高いと考える </li></ul><ul><li>スレッド専用メモリ=キャッシュヒット率がものすごく Up! </li></ul>
  74. 74. ところで free するときに、自分の所属する arena ってどうやって見つけるんだっけ?
  75. 75. だめアイデア1 <ul><li>TLS から arena を取得 </li></ul><ul><li>-> 自分専用 arena を作る前に </li></ul><ul><li> 何回か main_arena から取得 </li></ul><ul><li> している分がある。 </li></ul><ul><li> それは、 main_arena に戻さないと。 </li></ul>
  76. 76. だめアイデア2 <ul><li>それぞれの malloc header に arena へのポインタを追加する </li></ul><ul><li>-> なんのために死ぬ思いでヘッダを </li></ul><ul><li> 4バイトまで削ったと思ってるんです? </li></ul>
  77. 77. だめアイデア3 <ul><li>main_arena (唯一のグローバル変数)から arena のリストをたどって・・・ </li></ul><ul><li>-> O(n) の検索はダメだっつってんだろ! </li></ul>
  78. 78. 結局どうしたか? <ul><li>arena を絶対 1M align されるようにメモリを確保する。 すると、 ptr & ~0xFFFFF するだけで arena へのポインタが得られるようにする </li></ul>
  79. 79. 課題 1 <ul><li>main_arena はグローバル変数なんだけど・・・ </li></ul>0 31 1 2 size 0 0 0 IS_MMAPED PREV_IN_USE -> 毎度おなじみ size メンバハックのお時間でございま~す♪ IS_NON_MAINARENA
  80. 80. 課題 2 <ul><li>Linux に 1M align を保障するメモリ確保システムコールってないんだけど </li></ul><ul><li>-> 以下のちょっとトリッキーな方法で可能     (次ページ参照) </li></ul>
  81. 81. Arena で 1M にそろえる方法 図解 0x100000 0x200000 こういうメモリ確保がしたい しかし mmap では出来ない。 low high use free free 1 M アライン
  82. 82. Arena で 1M にそろえる方法 図解 0x100000 0x200000 2 倍のサイズで mmap ただし PROT_NONE 0x100000 0x200000 余分な場所を munmap READ も WRITE も EXEC も不可なメモリ確保というのは メモリを確保しないが、アドレススペースは確保するというのと同義 1M アラインされた場所から size 1M で PROT_READ | PROT_WRITE | PROT_EXEC で remap. 0x100000 0x200000
  83. 83. まとめ <ul><li>小さい malloc は回数がすごくたくさん呼ばれるので、 O(n) ではダメ </li></ul><ul><li>フラグメンテーションを防ぐには Huge   Block は Heap を分けるのが効果的 </li></ul><ul><li>キャッシュヒット率を上げるには、参照局所性 超 重要 </li></ul><ul><li>per Thread なデータ構造は per CPU なデータ構造のよい近似値 </li></ul>
  84. 84. glibc malloc のダメなところ <ul><li>Huge Block が絶対 page align されてしまうので、キャッシュが競合しやすい ( HPC 分野ではこの機能は OFF にするのが一般的) </li></ul><ul><li>もう一工夫すれば、 Arena へのロック自体なくせる(これが問題になるような heavy allocation アプリは自前 heap 管理をしてるので効果は見えにくいかも) </li></ul><ul><li>最新の dlmalloc は large-bin の管理がリストからバイナリツリーに変更されて高速化が図られている(でも使用率がいまいち低いので効果は微妙か?) </li></ul>
  85. 85. 終わりに変えて <ul><li>glibc malloc は、今日のスライド 90 枚にわたる色々なアイデアが int_malloc() という1つの関数にごった煮で詰め込んであるので、すごく読みにくい </li></ul><ul><li>おまいら、ソースコードのコメントにうそを書くなと小一時間・・ </li></ul><ul><li>おまいら、関数分割ぐらいしろと小二時間・・・ </li></ul><ul><li>おまいら、構造体の型とメモリ上のデータ構造は合わせておけと小三時間・・・ </li></ul><ul><li>これを見ると Linux kernel ってなんて読みやすいのかと・・・・ </li></ul>
  86. 86. ご清聴ありがとうございました! つかれた~ (≧ω≦) ゞ

×