7月版　新ファイルシステム「ext4」開発開始か

上川純一
日本ヒューレット・パッカード株式会社
コンサルティング・インテグレーション統括本部
2006/7/25

linux-kernelメーリングリスト（以下LKML）かいわいで起きるイベントを毎月お伝えする、Linux Kernel Watch。2006年6月はどのようなことが起きたのか、見てみましょう。

2.6.17カーネルリリース

　6月18日に、Linuxカーネル2.6.17がリリースされました。2.6.16のリリースが3月20日ですから、今回も3カ月ごとのリリースを維持しています。2.6.17での変更点としては、以前お伝えしたspliceやteeなど、いくつかのシステムコール追加が目に付きます。

　Andrew Mortonはこのリリースを受けて、今後の2.6.18へのマージ計画を「2.6.18 -mm merge plans」としてLKMLに投稿しました。各パッチについて検討を促す巨大なメールです。それに対して、各担当者がそれぞれ回答を返す形で長いスレッドを形成していました。これを見たAlan Coxは、「7月中旬のカーネルサミットで議論しようよ」と呼び掛けました。

　2.6.18がどうなるのか。カーネルサミットでの議論が大きく影響しそうですね。

関連リンク：
	カーネル2.6.17 http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.17.6.tar.bz2

突破口の見えないvgetcpuの実装

　最新のAMD Opteron Rev.Fには、新しい命令RDTSCPが実装されています。それを利用して、「『現在命令を実行中のCPUを取得する関数vgetcpu』をvsyscallとしてx86_64アーキテクチャに実装しよう」という提案がありました。Andi Kleenたちは、その実装のためのパッチをLKMLに投稿しました。

　RDTSCPにより、Rev.Fでは高速なvgetcpuを実装することができました。問題は、RDTSCPを実装していないCPUです。そうした既存のCPUでもvgetcpuを使えるようにする試みが始まり、その議論で盛り上がりました。

　CPUID命令を使えば、現在実行中のCPUを確認できます。しかし、CPUID命令は実行時にCPUサイクルを多く消費します。Andi Kleenは、さまざまな方式で実装したvgetcpuおよびシステムコール（getpid）が必要とするCPUサイクルを計測し、その結果をLKMLに投稿しました。

Opteron Rev.E Opteron Rev.F Pentium-D Smithfield 備考 getpid 162 162 719 単純にシステムコールを発行しているだけの場合（オーバーヘッドの例） vgetcpu 185 145 535 vgetcpu命令をCPUID命令で実装した場合 vgetcpu （キャッシュ） 15 14 27 vgetcpuにキャッシュ機能を実装した場合 vgetcpu （RDTSCP） 　 32 　 vgetcpuをRDTSCP命令で実装した場合（Opteron Rev.FのみRDTSCPを実装） Andi Kleenによるベンチマーク結果

　CPUの種類によって多少の違いはありますが、システムコールを発行した場合が最もCPUサイクルを消費し、CPUID命令はシステムコールの場合に近いCPUサイクルを必要とすることが分かります。

　Andi Kleenはこの問題に対応するために、vgetcpuの仕様を「CPUID命令を毎回呼び出すのではなく、一定時間その結果をキャッシュしておく」ことにしたそうです。これが、ベンチマーク結果の「キャッシュ機能を実装した場合」です。CPUサイクルの大幅な削減を実現していますが、キャッシュが有効な間にそのスレッドを実行しているCPUが変わると、間違った値を返すことになります。当然のことながら、「このような仕様のvgetcpu命令は正しいのか？」という議論が発生しました。

　一方、Chuck Ebbertはx86_64用のパッチに負けじとi386向けのパッチを投稿しました。GDTのうち、利用していない領域（limit）をCPUごとのデータの保持に使うというものです。LSL（load segment limit）という機械語命令を利用することで、ユーザー空間からその情報を読み込むことができます。

　ただ、この提案についてLinus Torvaldsは、「現時点でも比較的遅いLSL命令は利用頻度が少ない。そのため、今後のCPUでもあまり最適化されないはずで、より遅くなっていくだろう。そういう命令に依存するとパフォーマンスがCPU依存になってしまうのではないか？」と、この手法に疑問を呈しました。

コラム　RDTSCP

RDTSCPは、RDTSCを改良した命令です。RDTSCは1命令で1増加するカウンタであるTSCを読み込む命令です。以前お伝えしたように（2005年12月版、2006年2月版）、x86_64では実行しているCPUによって値が変わってしまうという問題がありました。 　 RDTSCP命令はTSCだけでなく、同時にTSC_AUX領域の中身も読み込みます。TSC_AUX領域はCPUごとに違う値を持たせることができるので、CPU番号などを埋め込んでおけば、どのCPUで命令が実行されているのかを確認できます。

関連リンク：
	AMD64 Architecture Programmers Manual, Volume 3, General-Purpose and System Instructions: http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/24594.pdf

リードオンリーでbind mount

　Dave Hansenは、bind mountをしたマウントポイントをread-onlyにするパッチを再投稿しました。最近はlinux-vserverなどの仮想環境が盛り上がっており、そうした環境では実用的なパッチです。そのためか、採用に一歩近付いているようです。

　bind mountとは、ディレクトリツリーの一部をほかのディレクトリに「あたかもファイルシステムであるかのように」マウントさせる仕組みです。例えば次のようなコマンドを実行すると、/source以下のディレクトリが/dest以下からも参照できるようになります。

# mount --bind /source /dest

　既存のbind-mountには、1つ欠点があります。それは、「-o ro」（読み込み専用）などのオプションを指定しても、元のファイルシステムをマウントした権限（通常はrw：書き込み可能）としてマウントされてしまうことです。

　この欠点が解消されると、管理用に書き込み可能な状態でマウントされているファイルシステムを、仮想環境用には読み込み専用のディレクトリとしてマウントし直すことができるようになります。例えば、/usrなどは各仮想環境で共有すれば管理が楽になります。ただ、それぞれの仮想環境で勝手にパッケージのインストールなどを行って内容が変更されるのは避けたいところです。read-onlyでマウントできれば、こうした環境を実現できます。

　read-only bind mountが実装されると、次の手順でread-onlyに変更できるそうです。

# mount --bind /source /dest # mount -o remount,ro /dest

　read-only bind mountは、-mmツリーに統合されました。今後メインラインにマージされて一般に広まれば、便利に使えそうです。

1/2

Index Linux Kernel Watch　7月版 　新ファイルシステム「ext4」開発開始か

Page 1 　2.6.17カーネルリリース 　突破口の見えないvgetcpuの実装 　リードオンリーでbind mount 　 Page 2 　ext4ファイルシステムへの道 　4KSTACKSの場合割り込みがカウントされないバグ 　-stableの進ちょく

連載 Linux Kernel Watch

---

Linux Squareフォーラム Linuxカーネル関連記事

	連載：Linux Kernel Watch（連載中） Linuxカーネル開発の現場ではさまざまな提案や議論が交わされています。その中からいくつかのトピックをピックアップしてお伝えします
	連載：Linuxファイルシステム技術解説 ファイルシステムにはそれぞれ特性がある。本連載では、基礎技術から各ファイルシステムの特徴、パフォーマンスを検証する
	特集：全貌を現したLinuxカーネル2.6［第1章］ エンタープライズ向けに刷新されたカーネル・コア ついに全貌が明らかになったカーネル2.6。6月に正式リリースされる予定の次期安定版カーネルの改良点や新機能を詳しく解説する
	特集：/procによるLinuxチューニング［前編］ /procで理解するOSの状態 Linuxの状態確認や挙動の変更で重要なのが/procファイルシステムである。/procの概念や/procを利用したOSの状態確認方法を解説する
	特集：仮想OS「User Mode Linux」活用法 Linux上で仮想的なLinuxを動かすUMLの仕組みからインストール／管理方法やIPv6などに対応させるカーネル構築までを徹底解説
	Linuxのカーネルメンテナは柔軟なシステム カーネルメンテナが語るコミュニティとIA-64 Linux IA-64 LinuxのカーネルメンテナであるBjorn Helgaas氏。同氏にLinuxカーネルの開発体制などについて伺った
	more

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）