最近の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が性能にインパクトを与えるぐらい、すごくでかいデータへのアクセスが発生しており
・シングルスレッドアプリケーションである
場合はお手軽な高速化としていいんじゃないでしょうか。


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



そっくり！　ランキング！