Orz日記 by Akio Morita

_ [SAD]filevmアロケータアイデア

思いつきメモ

MAP_GUARD拡張を使ったvmアロケータはmmap(2)の拡張に依存するので移植性がないので、POSIX/SUSで移植性のあるアロケータのアイデアをメモメモ

初期化手順

• mkstemp(3)でbacking store fileをopen
• file system namespaceからunlink(2)する
• ftruncate(2)で、16GiBへ拡張する
• mmap(2)でbacking store fileを仮想メモリに割り当てる
• mprotect(2)で、一旦書き込み禁止にする or mmap(2)時点で PORT_NONEで割り当てる

割り当て

• backing store fileから新規割り当て領域分をmprotect(2)でPORT_READ|PORT_WRITEに変更する
  • 実際のページ割り当ては、Copy on Write時に行われる

リソース使用量の考察

• ftruncate時点では、hole fileなのでfile system blockは未割り当て
• 書き込み時のCopy on Write動作で、VM block割り当てが実施される
  • 未初期化ページのbacking storeはhole file backedなので、VMが最適化されていればzero fillされた単一のdummy pageで賄える
  • MAP_PRIVATEで割り当てるとCoWされたpage差分は、anonymous pageとしてVMから割り当てられる
    • over-commit有り環境だと、MAP_GUARD拡張による実装に近い動作になる
    • over-commit無し環境だと、VM backing storeが不足するとmmap(2)の時点で弾かれる点で、MAP_GUARD拡張実装と異なる
  • MAP_SHAREDで割り当てるとCoWされたpage差分は、file backed pageとしてVMから割り当てられ、適宜write backされ page drop対象になる
  • madvise(2)等でWrite Back動作を制御しないと、不要なWriteBackが負担になる
• 終了時は、file descriptor開放に伴い link count zeroとなりfile systemから開放される
  • Write backを発生させる場合、I/O性能的にlocal file system上が望ましい

実装上の考察

• 32bit環境のケースのfallbackは実装すべき
• MAP_GUARD拡張によるbackendと類似の構造になるので、コードの共通化を考えるべきか？
• 最初の初期割り当てサイズを制限するノブを付けておいたほうがよい (メモリリーク時に早期にアボートさせる用)
• MAP_SHAREDなbacking storeを採用する場合、backing storeのパスを設定可能にすべき