WSL 2 のファイルシステムパフォーマンス向上（デバイスごとの SWIOTLB プール）

WSL 2 は、DMA 層の主要な競合ポイントを排除することで、クロス OS のファイルシステムアクセスを改善しています。2026年5月にマージされた変更（PR #40654）により、各 virtio デバイスに専用の DMA プールが割り当てられ、ネットワークアダプタや複数のドライブマウントなど、複数デバイスが同じメモリバッファを競合する際の I/O ボトルネックが防止されます。

Virtiofs 用デバイスごとの SWIOTLB プール

Hyper‑V 上の仮想マシンは、I/O を実行するためにバウンスバッファ（4 GB の DMA 境界以下に確保されたメモリ領域）を使用します。Linux カーネルではこれらは SWIOTLB プールと呼ばれます。従来、WSL 2 セッション内のすべての virtio デバイスは単一のグローバルプールを共有していました。その結果、/mnt/c の virtiofs マウント、/mnt/d のマウント、そして virtio ネットワークアダプタが同じバッファにキューイングされ、重い I/O ワークロード時に大きな競合が発生していました。

PR #40654（作者：Ben Hillis）は、起動時に 4 GB 未満の連続した物理領域を割り当てることでこの問題を解決します。WSL サービスは sysfs から swiotlb_base と swiotlb_size を読み取り、デバイス作成時にデバイスごとの swiotlb= オプションを注入します。これにより、各 virtio デバイスが専用の DMA プールを持ち、共有キューのボトルネックが取り除かれます。

技術要件

  • Kernel Version: Microsoft.WSL.Kernel 6.18.26.3-1 以上。
  • WSL 2 DeviceHost: バージョン 1.2.29-0。
  • Memory: WSL 2 セッションは 1 GB 以上の RAM が必要です。SWIOTLB プールには少なくとも 64 MB の余裕が必要です。

クロスOSワークフローの最適化

このアップデートは、Windows ドライブ上（例：/mnt/c/Users/you/code）にあるプロジェクトで cargo build、npm install、mvn package などを実行する、Windows と Linux の境界を跨ぐファイル集約型ワークフローを対象としています。DMA の競合を減らすことで、virtiofs のパフォーマンスがさらに向上します。

最適化を有効にする方法

virtiofs はまだオプトイン機能であるため、ユーザーは手動で有効化しなければこれらの効果を得られません。

  1. .wslconfig ファイルの [wsl2] セクションに virtiofs=true を追加します。
  2. 次のコマンドで WSL カーネルを更新します：wsl.exe --update --pre-release。

WSL ファイルシステムアクセスの進化

クロス OS のファイルアクセスは、パフォーマンスギャップに対処するために 3 つの主要なアーキテクチャシフトを経て進化してきました。

  • WSL 1 (DrvFs): Windows NT カーネル内のカスタムファイルシステムドライバを使用しました。VM の境界がないため、ファイル集約型ワークロードに対して高速でした。
  • WSL 2 (Plan 9/9P): Hyper‑V VM 内にフル Linux カーネルを導入しました。初期のクロス OS アクセスは Hyper‑V ソケット上の Plan 9（9P）ファイルサーバーを使用しましたが、64 KB のメッセージサイズ制限（msize=65536）によるプロトコルオーバーヘッドが問題でした。
  • WSL 2 (virtiofs): 共有メモリファイルアクセスのために VirtIO トランスポートを使用する実験的オプトインとして導入され、9P に比べてシリアライズオーバーヘッドが大幅に削減されました。

コミュニティの視点とトレードオフ

技術的な改善は DMA 層の修正ですが、コミュニティの議論ではネイティブ Linux 体験と WSL 2 仮想化層との間に持続的な緊張が指摘されています。

"WSL は開発者が Windows から離れる潮流を大きく食い止めましたが、WSL のネイティブファイルシステム性能は、初めて Linux を起動したときに開発者に魔法のような体験を提供し、ファイルシステムが必ずしも遅くなる必要はないことを示しました。"

一部のユーザーは、virtiofs がギャップを埋めるものの、VM の境界によるオーバーヘッドを完全に回避するためにローカル開発ではネイティブ Linux や macOS を好むと指摘しています。また、WSL 1 のシステムコール変換層から WSL 2 の VM ベースアプローチへのアーキテクチャシフトは、システムコール互換性を向上させる代償として当初はファイルシステム性能を低下させたというトレードオフでもありました。

その他の報告された利点として、WSL の起動が高速化し、同じ DMA インフラストラクチャを利用する VirtioProxy のネットワーキング性能も向上したことが挙げられます。

Sources