1月版　スケジューラの挙動は三巨頭会談で決まるのだ？

小崎資広
2009/1/30

　お久しぶりです。筆者は今月、オーストラリアはタスマニア島で開催されたlinux.conf.au 2009に参加してきました。おかげで原稿の締め切りが大幅に前倒しになって大変だったのですが、なかなか貴重な体験ができました。

　まず、言葉が全然通じません。彼らの発音だと「name」が「ナメ」なんですよ。パブとかでフランクな人に話しかけてこられたりすると超ピンチ、冷や汗出まくりです。もう1つ面白かったことがあります。タスマニア島というとタスマニア・デビルぐらいしか知らなかったのですが、現地の方の間では宮崎アニメの「魔女の宅急便」の舞台となった場所だと認識されていることです。主人公が働いていた「ぐーちょきパン屋」の元になったとされるパン屋さんが、州都から北に1〜2時間ほど走った郊外にあるのだとか。意外なところで文化交流があるものです。

　さてLKMLはというと、先日、2.6.29のマージウィンドウが閉じられましたが、何といっても一番のトピックは「btrfsのマージ」でしょう。

　ほとんど全員がマージに条件を付けていたのに、全部無視しての無修正マージに一同びっくり。Linusったら、本当にメール読んだんかいな？ 数日後には早速Andrew Mortonから「Congratulations ;)」という1行とともにバグ報告が転送されてきて、一同、二度びっくり。「バグ満載やんかー」！

関連記事：
	Linux用次世代ファイルシステム「btrfs」が統合へ（＠IT News）

　さて、今回は2008年のクリスマスにリリースされたばかりの2.6.28の変更点を中心に見てみましょう。それでは、どうぞ。

トピック満載の2.6.28リリース

　今回はメモリ、ファイルシステム、ブロックレイヤに大きな変更がありました。ざっと見ていきましょう。

お断り：今回のトピックのうち、「メモリ管理のスケーラビリティのさらなる改善」と「hugepageのコアダンプ機能サポート」は、主要開発者に筆者が名を連ねています。自画自賛になるので外そうかとも思ったのですが、トピックとして大きいのでそのまま載せました。そういうわけですので、当該部分は若干色付きメガネで見ていただけると助かります。

■メモリ管理のスケーラビリティのさらなる改善

　「Linuxメモリ管理の最先端を探る」の「VM（仮想メモリ）の改善」で書いた「Split-LRU」パッチがマージされました。技術的な中身はそちらを見ていただくとして、筆者が個人的にもらっているフィードバックでは、S390＋kvm＋メモリ45GBの環境で動かしていたWebSphereで、従来は80インスタンスが限界だったのが、200インスタンス以上生成できるようになったそうです（しかも、swapd bandwidthがボトルネックであることが分かっているので、I/O機器の高速化によってさらにスケールできそう、とも）。

　アプリケーションサーバはWebサーバよりも集約しにくく、どうしてもサーバ台数が増えてしまう傾向にあったので、大規模サーバユーザーにはうれしいお知らせかもしれません。

　また、HPCのようにmlock()を多用するケースにおいては、いままでの実装では、一度メモリ回収が始まると回収が遅過ぎて永久に回収処理が終わらなくなる危険がありましたが、それも解消されています。

関連記事：
	Linuxメモリ管理の最先端を探る http://www.atmarkit.co.jp/flinux/rensai/watch2008/watchmema.html

■vmapレイヤの書き直し

　vmap()/vunmap()というのは、vmalloc()/vfree()のヘルパー関数的な役割の関数で、仮想アドレスの切り張りを受け持っています。

　これまで「vmalloc()は一応あるけれど遅いので誰も使わない、誰も使っていないので誰も改善しない」という負のループがあり、何年も放置され続けてきました。特にvunmap()を実行するためには、全CPUのTLB（簡単にいうと、仮想アドレスの変換キャッシュです）をフラッシュする必要があり、「自分以外の全CPUに割り込みを送信し、しかる後TLBフラッシュの完了を待つ」という実装になっていました。このため、CPU数が増えるのに比例して、処理がどんどん遅くなってしまっていました（CPUが何十個もあると、どれか1つぐらいは割り込み禁止中だったりするので、返事がすぐには返ってこないのです）。

　そこで発想を逆転させて、vunmap()呼び出し時には削除フラグを立てておいて、後から非同期処理でゆっくりと仮想アドレスのアンマップを行うことにより、割り込み返事待ちの遅延をなくしています。これにより、XFSで大きなディレクトリを操作するようなワークロードにおいて最大20倍の高速化が達成されたそうです。

■hugepageのコアダンプ機能サポート

　最近のCPUは、大体どのアーキテクチャでも「ラージページ機能」を備えています。これは通常よりも大きなページサイズを使うことができるようになる機能で、主にHPC分野で使われていました。Linuxではhugepage/hugetlbfsといった名前でサポートされています。

　従来、hugepageを使うにはちょっとややこしいプログラミングが必要でした。しかしlibhugetlbfsの改善により、ヒープだけのhugepage化ならLD_PRELOADするだけで、データセグメント（グローバル変数が格納されているところ）をhugepage化する場合でも再コンパイルだけでできるようになっています。

　こうなると、手間をかけずに性能が上がるので使わない手はない、という話になるのですが、1つ重大な欠点がありました。従来のhugepageでは、コアダンプ機能がサポートされていなかったのです。これでは、いざというときに障害解析ができないので、用途によっては使いものにならなくなってしまいます。

　そこで、coredump_filterの機能を拡張してhugepageのダンプ採取可否を制御できる機構が実装され、デフォルト値もhugepageかつプライベートマッピングのときは「コアダンプする」に変更されました。これは前述のlibhugetlbにおいて、ヒープとデータセグメントがプライベートマッピングで実装されているためです。

関連記事：
	2007年10月版　あんなコアいいな、吐けたらいいな http://www.atmarkit.co.jp/flinux/rensai/watch2007/watch10a.html

■ext4がstable宣言

　ext4が安定リリース宣言され、それに伴いマウント方法が「mount -t ext4dev」から「mount -t ext4」に変わりました。名前だけの変更なので新味はないですが、stableであると宣言されたことにより、ディストリビュータが安心してユーザーに提供できるようになりました。ユーザー数も大きく増えることが予想されます（注1）。

　筆者が1点だけ残念だったのは、オンラインデフラグ機能が間に合わなかったことです。先月、Ted Tsoが一から再設計するよう提案し、開発者も受け入れる方向です。ただ、一般ユーザーが安心して使えるようになるには、あと数カ月はかかるんじゃないかな？

注1：数日後、早速Fedora Projectから、「Fedora 11でデフォルトファイルシステムがext4に変更される」とアナウンスされました。

コラム■ext4 デフラグの最新トピック 　従来のデフラグはあまりに賢く作られ過ぎていて、ext4のコア部分のコードを変えるとデフラグコードが壊れてしまう危険性がありました。実際、そういうバグレポートが上がったのを契機に、「プリミティブなioctlを用意してユーザー空間側で頑張る」という案が提案されたようです。以下の3つのioctlが提案されています。 ある範囲のブロックがファイルシステムにアロケートされないよう予約する機能 あるinodeの指定したレンジに、指定したブロックを関連付ける機能 .2つのinode番号を受け取り、ドナーinodeのブロックと提供先inodeのブロックを交換する機能。ドナーinode側が連続したブロックを持っていれば、defragになる。

■ext3/4にI/Oエラー時の振る舞いを制御するマウントオプション追加

　ext3/4にマウントオプションが追加され、（メタデータではなく）データ書き込み時のエラーを無視するかどうかが選択できるようになりました。デフォルト値は無視です。

　実はこのオプション追加には、非常に込み入った歴史的な事情があります。

　当初の設計では、ext3のordered modeはデータのcorruptionについてはケアしないというポリシーになっていました。しかしながら、データ書き込み時のI/Oエラー発生時はjournal abortとして扱う（注2）というパッチが、2.6.11において（Andrew Mortonの弁によれば）「間違って」マージされてしまいました。

　ところがこの挙動で困る人が誰もいなかったので、約3年の間これが仕様のまま残り、また多くのディストリビューションが出荷されてしまいました。ところが、去年、Hidehiro Kawaiにより「jornal abortされないケースがあるバグを直す」というパッチが投稿された時点でこの間違いが発覚し、大騒ぎになりました。

　結局、Andrew Mortonの決断により

• ordered modeはメタデータのみを扱うのが仕様。いまのデータ部分のEIOをチェックしている部分は外す（2.6.27でマージされました）
• その代わり、Kawaiが提案しているデータのエラーを網羅的にチェックするモードをマウントオプションとして新設する（今回マージされました）

という形で解決することになりました。ややこしいですが、data_err=ignore（default値）だと従来とは違う挙動、data_err=abortが従来の挙動＋バグフィックスですので、お間違いなきよう。

注2：マウントオプションによりますが、通常はリードオンリーモードで再マウントされます。

1/2

Index Linux Kernel Watch　1月版 　スケジューラの挙動は三巨頭会談で決まるのだ？

Page 1 　トピック満載の2.6.28リリース 　 Page 2 　まだまだあるぞ新機能 　ついにLinuxにもadaptive lock導入か?! 　-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メールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）