LinuxCon/Multi-core Scalability on Modern Linux Kernels
Multi-core Scalability on Modern Linux Kernels
Andi Kleen, Intel Corporation
スケーラビリティとは
CPUやメモリを増やしていくことに対応すること。
より多くのスレッドを走らせることで可用性をあげるもので、リニアに性能があがるものではない。
Linuxサーバーはマルチコア、1TB以上のメモリを搭載するものがほとんどになった。
カーネルは大きなライブラリであり、データセットではない。
複数のユーザーが並行でこの処理を呼び、データ構造にアクセスする仕組みを提供するのが鍵になる。
スケーラビリティのdisadvantage
レイテンシ
複数CPUのデータシェアでは、参照カウンタをロックするので、ロック時にキャッシュラインがはずれ、パフォーマンスに影響する。
非常に処理コストが高い。
ネットワークシステムが代表的な例。
NUMAの問題
Code Lock vs Data Lock
最近のカーネルはコードロックは減らされてきている。
オブジェクトはネットワーク、SCSIホスト、ファイル・・
これらを並行して、効率よくキャッシュするように扱わなければならない。
Case study: global lock: dcache_lock
dcache_lockはグローバルロックを使う。
- dcache_lockのオーバーヘッド
- スレッド数にしたがってオーバーヘッドが増加する。
- dcache_lock とinode_lockを参照カウンタを減らすことで高速化させた。
ファイルシステム
DataIOはふつう、並行処理される。
しかし、複数のマウントポイントでうごかしてるとき、メタデータは複数のファイルシステムがそれぞれにロックする。
ディスクリプタごとにsyncしてしまい、ファイルシステムのパフォーマンスがアプリケーションに依存してしまう。
ext4はext3よりスケーラビリティが高い。
Extentsと新しいアルゴリズム
dataはO_DIRECTがベストだ。
ジャーナルスレッドがボトルネックになってるが、
近々、スケーラビリティに関する問題は修正されるだろう
XFS
XFSはスケーラビリティに関して、もっと良いロック機構をもつファイルシステムだ。
"allocation groups"で並行にアクセスできる。
並行にファイルを書き込むには有利になる。
large-I/Oで効果を発揮する。
btrfs
まだ開発中だ。まだスケーラビリティに関心がいってない。
ロックの問題がまだ残ってる。
Address spaces
Single lockでプロセスのアドレススペースを保護している。
mmap_sem
parallel page faults(並行でbrk/mmapを複数スレッドでやるとき)に問題が潜んでいる。
すべてのスレッドが単一のアドレススペースにヒットする
Workaround:
アプリケーションでmmaps/unmapsを減らす