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カーネルの開発体制などについて伺った

MONOist組み込み開発フォーラムの中から、Linux関連記事を紹介します

@IT Special

- PR -

TechTargetジャパン

Linux & OSS フォーラム 新着記事
@ITメールマガジン 新着情報やスタッフのコラムがメールで届きます(無料)
- PR -

イベントカレンダー

PickUpイベント

- PR -

アクセスランキング

もっと見る

ホワイトペーパーTechTargetジャパン

注目のテーマ

Linux & OSS 記事ランキング

本日 月間
ソリューションFLASH