11月版　x86系重複コードの悪夢は消えるのか？

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

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

長い長い開発サイクルを経てようやく登場した2.6.23

　10月9日に2.6.23がリリースされました。長い開発サイクルの結果であり、それなりに安定したリリースのようです。これを受けて、10月は2.6.24のリリースプラン関連の話題でLKMLが熱く盛り上がりました。

　10月24日に2.6.24-rc1をリリースしたLinusは、パッチのサイズについてコメントしました。通常のパッチのサイズは3～6Mbytes程度なのに、このリリースでは11Mbytesもあり、巨大です。後述する「x86マージ」がなされたため、多くのファイルが移動したことも1つの要因だったのですが、それだけでなく、ほかにも多くの変更がありました。

　Linusによると、ブロックレイヤのScatter Gather（これも後述します）の変更が最も多くの問題を引き起こしたのですが、それ以外に仮想メモリ（VM）レイヤや仮想ファイルシステム（VFS）レイヤにも変更があり、「正直、誰も変更に気付きすらしないことを願っている」とのことでした。

マージでx86系コードのスリム化なるか？

　Linux Kernelでは2.6.23までは、IntelのPentiumやAMD Athlonなどのx86プロセッサ用として、i386（32bitモード向け）とx86_64（64bitモード向け）の2つのアーキテクチャが存在しています。

　x86_64は、i386と同じCPUで、違いは64bitモードで動いていることだけです。このため、多くの内容が重複しているにもかかわらず、ソースコード上では別のディレクトリになっています。つまり、異なるディレクトリの間で多くのコードの重複が起きていたのです。

　x86マージとは、この現状を改善するためx86ディレクトリにソースコードを統合し、1つに統合できないソースコードは、ファイル名を_32.cや_64.cで終了するものに変更してしまおう、という動きです。

 linux-2.6$ ls -d arch/*/

              arch/alpha/    arch/frv/   arch/m68k/      arch/ppc/   arch/sparc64/

              arch/arm/           arch/h8300/  arch/m68knommu/  arch/s390/  arch/um/

              arch/avr32/    arch/i386/  arch/mips/           arch/sh/       arch/v850/

              arch/blackfin/  arch/ia64/  arch/parisc/       arch/sh64/  arch/x86/

              arch/cris/         arch/m32r/  arch/powerpc/     arch/sparc/  arch/xtensa/

Linux Kernelのarch以下のディレクトリの一覧

　Christoph Hellwigは、2.6.24-rc1のリリースアナウンスに対する返信として、「ところで、x86のマージを2.6.24のフリーズまでに完了できないだろうか？　arch/i386とarch/x86_64両方にファイルが残っているのはとんでもない悪夢だ。ほかのアーキテクチャのマージの場合はこうはならなかった」というメールを出しました。

　マージ作業を主として担当したIngo Molnarは、この要請に対する反応として、5年間分離し続けた結果、i386とx86_64のコードの差分が蓄積していることを説明するとともに、checkpatchスクリプトで機械的なチェックを行った結果を見ても、コードの品質が悪いことを挙げました。「マージは簡単な単純作業ではない。特に、マージを優先してコードの安定度を犠牲にするのは、ユーザーの望むものではないはずだ」と回答したのです。

ディレクトリ	errors	lines of code	errors/KLOC (smaller is better)
arch/i386/	5717	73865	77.3
arch/x86_64/	2993	31155	96.0
arch/x86/	8504	114654	74.1
arch/ia64/	1779	64022	27.7
arch/mips/	2110	94692	22.2
arch/sparc64/	1387	49253	28.1
kernel/	762	83540	9.1
kernel/time/	15	4191	3.5
kernel/irq/	1	2317	0.4
mm/	464	46324	10.0
net/core	176	24413	7.2

サブシステムごとに見た、checkpatch.plが1000行当たりで出力するエラーの量
（Re: Linux v2.6.24-rc1, x86 arch code quality, unifications、Ingo Molnar <mingo@elte.hu> より）

　Andi Kleenは、従来、x86_64アーキテクチャのメンテナとしての役割を担ってきました。一方i386については、Linuxの基本となるCPUだったからか、明確な1人のメンテナは存在していませんでした。

　現在は、Linux Kernelのサブシステムの担当者が誰かを明記するファイル（MAINTAINERファイル）に


X86 ARCHITECTURE (32-BIT AND 64-BIT)

というエントリができています。そこを見ると、Thomas Gleixner、Ingo Molnar、H. Peter Anvinの3名の名前が挙がっています。x86_64のメンテナを担当していたAndi Kleenですが、マージ後のx86アーキテクチャのメンテナは担当しないことになったようです。

　この変更は2.6.24-rc1でマージされ、少しずつ細かいところが修正されているようです。2.6.24-rc3では、「make ARCH=x86」や「make ARCH=x86 K64BIT=y」で設定が行えるように変更がなされたようです。2.6.24のリリース時にはどういう形で落ち着くのか、気になりますね。

SG chainingの導入でドライバ変更の大騒ぎ

　Jens Axboeの管理するblock treeの中で熟成され、2.6.24-rc1でとうとうマージに至った仕組みに「Scatter Gather chaining」（SG chaining）があります。

　SCSIディスクなどに対するデータの書き込みは、ブロックI/Oで実現しています。Scatter Gatherとは、転送用のデータ領域として、のアドレスと長さを配列として指定した複数のメモリブロックをばらばらに（Scatter）用意しておき、ドライバ側でデータブロックをまとめて（Gather）ハードウェア側に処理の依頼を発行できる仕組みです。

　この仕組みで利用している配列「scatterlist」は、従来は8、16、32、64と128の固定長で用意されていました。これは、I/Oを実行する段になって動的にメモリを確保するのは現実的でないため、事前にプールとして確保しておこうという設計指針によります。

　ところが、最近のデバイスで高速なI/Oを実施するためには、より多くのメモリ領域を同時に処理できる仕組みの方が好ましいのです。固定長の設計のままだと、固定で確保するメモリのサイズを大きくするか、それとも動的に確保できるようにするべきかというところが悩みのタネになります。

　これを解決するために、scatterlistの最後のエントリが次のscatterlistへのポインタとなり、連結リストとして利用できる仕組みが導入されました。これがScatter Gather chainingです。

　Scatter Gather chainingによって、従来は単なる配列だったものが、変則的な連結リストの処理に変わりました。このため、単純なループだったコードを書き換える必要があります。この変更のため、数多くあるSCSIの各ドライバにまで手を入れる必要が生じました。

　この変更に失敗すると、ディスク上のデータが壊れてしまうため、デバッグもやりにくそうですね。藤田智成氏は果敢にも各種部分の変更に挑戦しており、各種LLD（Lower level drivers）を修正するパッチを大量に投稿していました。

　SCSIでのScatter Gatherの仕組みでは、I/Oデバイス向けに仮想アドレスを管理する機構であるIOMMUの仕組みとの調整も必要になります。メーリングリストでは、藤田智成氏がIOMMUのパッチを投げたところ、うまく動かないため、SPARCアーキテクチャのメンテナ、Dave Millerが悩みながらデバッグしている光景が見られました。

　ともあれScatter Gather chainingの成果として、大規模システムなど、大量のディスクI/Oがある環境でのパフォーマンス向上が期待できそうです。果たしてどのくらいの成果が出るのでしょうか。2.6.24のリリースによって、広く評価されていくことに期待です。

参考：
	Linux Foundationでの藤田智成氏の発表資料 http://www.linux-foundation.jp/modules/tinyd5/index.php?id=7

1/2

Index
Linux Kernel Watch　11月版　x86系重複コードの悪夢は消えるのか？

	Page 1 　長い長い開発サイクルを経てようやく登場した2.6.23 　マージでx86系コードのスリム化なるか？　SG chainingの導入でドライバ変更の大騒ぎ
	Page 2 　x86以外のプラットフォームにもKVMを　-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

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

Linux ＆ OSS フォーラム新着記事

【 pidof 】コマンド――コマンド名からプロセスIDを探す （2017/7/27）
本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、コマンド名からプロセスIDを探す「pidof」コマンドです。
Linuxの「ジョブコントロール」をマスターしよう （2017/7/21）
　今回は、コマンドライン環境でのジョブコントロールを試してみましょう。X環境を持たないサーバ管理やリモート接続時に役立つ操作です
【 pidstat 】コマンド――プロセスのリソース使用量を表示する （2017/7/21）
本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、プロセスごとのCPUの使用率やI/Oデバイスの使用状況を表示する「pidstat」コマンドです。
【 iostat 】コマンド――I/Oデバイスの使用状況を表示する （2017/7/20）
本連載は、Linuxのコマンドについて、基本書式からオプション、具体的な実行例までを紹介していきます。今回は、I/Oデバイスの使用状況を表示する「iostat」コマンドです。