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してしまい、ファイルシステムのパフォーマンスがアプリケーションに依存してしまう。

ext4ext3よりスケーラビリティが高い。
Extentsと新しいアルゴリズム


dataはO_DIRECTがベストだ。

ジャーナルスレッドがボトルネックになってるが、
近々、スケーラビリティに関する問題は修正されるだろう

XFS

XFSはスケーラビリティに関して、もっと良いロック機構をもつファイルシステムだ。
"allocation groups"で並行にアクセスできる。
並行にファイルを書き込むには有利になる。
large-I/Oで効果を発揮する。

btrfs

まだ開発中だ。まだスケーラビリティに関心がいってない。
ロックの問題がまだ残ってる。

Virtual Memory subsystem

NUMAのページ開放メカニズムにいくつか問題がある。
 zone->lock

非常に大きなメモリサイズに対応するための作業が進んでいる。

Address spaces

Single lockでプロセスのアドレススペースを保護している。
mmap_sem

parallel page faults(並行でbrk/mmapを複数スレッドでやるとき)に問題が潜んでいる。
すべてのスレッドが単一のアドレススペースにヒットする

Workaround: 
アプリケーションでmmaps/unmapsを減らす

Networking basics

基本的に、TCP/IPネットワークスタックは非常にスケーラブルだ。
スケーラビリティに関しては深刻な問題はない。
オブジェクトロックはまだ問題が残っている。
ソケットのとことか。

Networking multi-queue
→現在開発中。
sysfsのチューニングが必要。
古いカーネルでは動作しない。

スケジューラ

本来、スケジューラはCPUごとに主要キューが走るはずだ

アルゴリズムの問題

新しいカーネルで、リアルタイムスケジューラはスケーラブルじゃない。
Attempts"global"real time fairness
Some workarounds possible using cpusets

sysytemtimeを参考に解析を進めている。
→ツール:SystemTap,ftrace