プロフィール

kosaki

Author:kosaki
連絡先はコチラ

ブログ検索
最近の記事
最近のコメント
最近のトラックバック
リンク
カテゴリー
月別アーカイブ
RSSフィード
FC2ブログランキング

スポンサーサイト このエントリーをはてなブックマークに追加

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。


スポンサー広告 | 【--------(--) --:--:--】 | Trackback(-) | Comments(-)

libhugetlbfs を解析してみた このエントリーをはてなブックマークに追加

最近のFedoraにはアプリケーションを自動的にHugetlbで動かしてスピードアップしてくれる、libhugetlbfsというパッケージがある。
という極秘情報をKAMEさんから入手して特派員は調査に向かった!!


うーん、おいらが作ってたライブラリとそっくり!

・mallocの乗っ取りはglibc mallocの__morecoreシンボルを乗っ取っている。
・mallocの乗っ取りはコンパイル済みのアプリにも有効
・text/data/bssの乗っ取りはld という名前の独自スクリプトを用意して、リンカオプションに --hugetlbfs-link= という文字列が現れたら、libhugetlbfsが用意した独自リンカスクリプトを引数文字列に追加して本物のldをinvokeしている
・つまりtext/data/bssのhugetlbfs化は再コンパイルが必要
・このリンカスクリプトでは以下の処理をおこなう
 ELFのセグメントヘッダのflagsに 0x100000を足す
・で、libhugetlbfs.soのコンストラクタで、flagsで0x100000 ビットが立っているセグメントをunmapしてHugetlbfsでもう一度mapする

うーん、この超すくない行数でここまでやるとは立派。
あえて欠点を指摘するなら以下だけど、たいした欠点じゃないような

・glibc mallocはメインスレッド以外の領域はmmapで確保するのだけど___morecore(よーするにsbrk)しかhookしてないので、メインスレッド以外のmallocはHugetlbにならない
・ELFの規格を無視したアヤシゲなフラグを勝手に導入している
・text/data/bssの処理は一度カーネルとld.soがマップしたトコロをもう一度アンマップしているので若干無駄
・あと、libhugetlbfs.so のコンストラクタが、他のコンストラクタよりも先に走る事を前提に決めうってアンマップしているので、LD_PRELOAD以外でlibhugetlbfs.soをリンクすると悲惨
・hugetlbfsにファイル作る、すぐさまunlinkする。という手法でプロセス終了とともに消えるファイルをつくっているので、変なタイミングでプロセスが終了するとhugetlbメモリが解放されない


まあ、課金やらジョブ毎のメモリ量制限とかの、ジョブ運用の要件は満たせないんで、結局大規模センター系はこれじゃダメなんだけど。。

てゆーか、2.6.16 を仮定(hugetlbfsのMAP_PRIVATEを仮定)してる時点でずるいよな!!


とりあえずアレだ
・マシン全体で特定のアプリしか動かしていなようなサーバーであり
・当該プロセスが落ちることはまず考えられず
・当該プロセスがforkとかせず
・当該プロセスがTLB missが性能にインパクトを与えるぐらい、すごくでかいデータへのアクセスが発生しており
・シングルスレッドアプリケーションである
場合はお手軽な高速化としていいんじゃないでしょうか。


追記:
そうそう、スタックのラージページ化も出来ないよ


キ○キス.jpg
そっくり! ランキング!
関連記事


linux | 【2007-02-28(Wed) 17:08:45】 | Trackback:(0) | Comments:(0)
  1. 無料アクセス解析
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。