SSDAlloc と Slab Allocator

Fusion-IO の Auto-Commit Memory が SSDAlloc という技術を用いているかもしれないとのことで，SSDAlloc の説明を読んでいた．

SSDAlloc

http://www.cs.princeton.edu/~abadam/ssdalloc.html

要点を以下にメモ書きする．

既存のプログラムで Flash-SSD を活かそうと思うと，これまでは 2 つの選択肢があった．

1. プログラマがプログラムを書き換える
   • たいていは Flash-SSD の特性（ランダムな書き込みが遅い）を活かすように，Flash-SSD は追記型ストレージとして使い，よくアクセスされるデータはメモリに置く，というポリシーでデータを扱うように，プログラムを書き換える
   • こんなのエキスパートのプログラマじゃないと無理だね
   • そして車輪の再発明を何度も行うのだろうね
2. スワップ領域を Flash-SSD にしてしまう
   • プログラムを書き換える必要はない
   • Flash-SSD の利点を活かすためにはページサイズを小さくしたい
     • でも，ページサイズって OS 全体に影響しちゃうよね
     • 特定のアプリケーションだけを Flash-SSD に特化させたいときにこれではダメ
   • また，スワップやファイルシステムは Flash-SSD に特化していないことが多いので，ランダム・大量な書き込みが生じてしまうことも

これに対し，SSDAlloc は Slab Allocator なメモリアロケーションインタフェースを提供し，裏側で透過的に Flash-SSD とメモリへの書き込み処理を行う．そのため，既存のアプリケーションでの malloc/calloc を SSDAlloc に置き換えるだけで，Flash-SSD を活かしたアプリケーションが実現できる！　（LD_PRELOAD を使えばもっと簡単に置き換えができそうだ）

疑問点

そもそも，何のために使われるものか？　なぜメモリアロケーションインタフェースとして提供する必要があるのか．

• 大容量の主記憶として Flash-SSD を利用するため？
  • 容量あたりの値段を考えると Flash-SSD は DRAM よりも断然安価，という理由
• 永続的なメモリとしての利用？
  • Flash-SSD は永続デバイス
  • この場合，コミットや sync がどう扱われるか気になるところ
    • そういったインタフェースがあるのだろうか？

Slab Allocator

Slab Allocator は以前 OS について勉強した時に出てきたが，すっかり頭から抜け落ちていた．Wikipedia で復習．

http://en.wikipedia.org/wiki/Slab_allocation

ざっと眺めただけなのでアレだが，次のようなところか．

• カーネル内で使われるオブジェクトの初期化は，メモリのアロケーション処理よりも遅い
  • そのため，オブジェクトはキャッシュしておき，オブジェクトの初期化を抑制するアプローチをとりたい
  • といっても，メモリを何回もアロケートするのは効率が悪く，メモリのフラグメンテーションを引き起こす
• そこで，カーネル内で使われるオブジェクト用に，あらかじめクラスのサイズ（構造体）に応じたメモリの固まりをアロケートしておく．この固まりは Cache と呼ばれる
  • ひとつの Cache は，複数のメモリ領域からなることがある
  • Cache を構成するそれぞれの連続したメモリ領域（ページサイズの定数倍？）が Slab と呼ばれる

確保するメモリ領域のサイズが，あらかじめ作成されうると分かっているオブジェクトのサイズと同じになる，という部分がポイントだろう．

ここまで書いて，Drizzle などで有名な前坂さんによるありがたい解説記事を発見した．

http://gihyo.jp/dev/feature/01/memcached/0002