第3回　メインフレームLinuxの実装（前編）

日本アイ・ビー・エム株式会社
システムズ＆テクノロジー・エバンジェリスト
北沢 強
2008/9/8

パッケージ移植はほぼスムーズに

　Linuxに対応したパッケージはたくさんありますが、われわれは、手分けして片っ端からコンパイルしていきました。実験環境でベースにしたのはRed HatのSource CDでした。PC LinuxにSource CDをマウントし、メインフレームLinuxからNFSマウントしてアクセスし、ひたすらビルドしていきました。

　実は、多くのパッケージではソースコードの修正が必要なく、リコンパイルしただけでメインフレームLinuxで稼働できてしまいました。その最大の理由は、GNU Autotoolsがかなり普及していたためです。

　GNU Autotoolsは、autoconf、automake、libtoolで構成されるツール群で、ハードウェア・アーキテクチャやOSプラットフォームなどの環境に合わせたMakefileを生成するものです。これに準じて開発されたプログラムは、移植を前提にしているため、環境依存部分だけをカスタマイズすれば、たいていの場合、configureしてmakeしてmake installすれば実行できてしまいます。

　1999年時点で、Linuxに対応した主要なパッケージは、ほとんどがすでにGNU Autotoolsに対応済みでした。もちろん、パッケージの開発者の多くが複数プラットフォームに対応することを意識してコーディングしているということも大前提となります。このような好条件が重なり、ほとんどのパッケージは修正なく移植できたのです。

　ただし、中には修正が必要だったものもありました。主要な理由としては以下の2つがあります。

• インラインでアセンブラコードが含まれる
• エンディアン依存コードが含まれる

　パフォーマンス重視のところはアセンブラで書くのが常とう手段です。例えばPostgreSQLでは、ロック制御（test-and-set）のところがインラインアセンブラで記述されていますので、そのような個所については移植作業の中でアセンブラで書き直す必要があります。ソースコード中のインラインアセンブラは修正すべきことが明確なので、移植することは容易です。

　しかし、エンディアン依存がソースコード中に含まれている場合は厄介です。

　エンディアンとは、複数バイトをメモリ上に配置する方式のことで、アーキテクチャに依存します。メインフレームはビッグ・エンディアンですが、PCに使用されるIntelアーキテクチャはリトル・エンディアンです。Linuxの開発者のほとんどはPC上で作業しているでしょうから、リトル・エンディアンの環境で開発し、テストをしていることになります。

　ここでよくあるトラブルとしては、関数やサブルーチンを呼び出すときに構造体や可変引数で引き渡すva_argsで問題が起こったり、キャストして型変換をしたときにバイト列の順番（byte order）が逆転してデータが化けたりします。これは、ソースコードを眺めただけでは見つからない場合も多く、実行した結果を見て初めて気付いて問題になるケースもあります。

　現在では、エンディアンの問題は多くの開発者によって認知され、意識して開発されていますので、当時に比べるとほとんど問題にはならなくなりました。

ベンチマークテストの意外な結果

　こうして一通りの移植が完了し、一人前のLinuxがメインフレーム上で稼働を始めました。エンジニアであれば、誰でも最初にやりたくなるのが、ベンチマークツールを使ったパフォーマンステストでしょう。どのくらいの性能が出るのか気になるところです。

　多くのベンチマークツールは複数のプラットフォームに対応しており、Linuxのように移植性が高かったので、メインフレームへの移植は容易でした。ByteMark、SPECint、SPECwebなど、さまざまなテストツールを流しました。

　しかし、その結果は期待に反するものでした。テストシナリオによっては、手元にあるPCよりも遅いという結果が出たりしました。

　ベンチマークテストツールでは、実際のアプリが稼働する環境とは負荷の掛かり方が異なるので、必ずしも実アプリ環境での性能を適切に示すものとは限りません。しかし、PCに比べるとかなり高価なメインフレームでLinuxを動かしても、PCと性能に差がないという結果には驚きました。また、I/O処理が多くなるほどメインフレームは強く、CPUインテンシブな処理が多くなるほどメインフレームが弱い、という傾向がありました。

　命令トレースによってこの原因を分析した結果、以下の理由によるものだと判明しました。

• 当時のgccによる生成コードはi386と互換命令のみしか使用しておらず、メインフレームが持つ900種類もあるハードウェア命令のうち、実用上は60種類程度しか使用されていなかった
• IEEE浮動小数点演算命令を、マイクロコードの中でエミュレーションしていた

　メインフレームはCISCプロセッサですから、さまざまな高機能命令がそろっているのですが、それらを使わずに単純命令を組み合わせて処理するため、パスレングスが長くなり処理効率が落ちていました。

　また、Linuxの中で多用されるIEEE 754二進化浮動小数点演算は、もともとメインフレームがサポートしていたエクセス64形式とは異なるため、10年前の当時のハードウェアでは、マイクロコードによってIEEE 754形式をエミュレーションしていました。マイクロコードはソフトウェアですので、CPU内の回路に比べて数倍も遅いことになります。

　このほかにも、カーネル内やglibcにはチューニングの余地がたくさんありました。

　現在では、ハードウェアも改良されて、IEEE 754形式をCPU回路で処理するようになり、gccも最適化ロジックなどでチューニングされてきました。これにより、当時に比べ1けた以上高速化されており、パフォーマンスが問題になることはなくなりました。

　ただ、メインフレーム上でLinuxのインスタンスを1つだけ稼働させてパフォーマンステストをして、その結果から価格性能比を割り出しても、メリットは見いだせません。やはり1台のメインフレーム上にたくさんのLinuxを稼働させ、システム統合運用できるところにメリットがあるわけですから、統合環境での性能評価の方法や指標については今後の研究課題であると考えています。

そして公開へ

　第1回で解説しましたが、メインフレームLinuxの存在は、移植した当初は社外秘でした。しかしながら、パイロットとして試用したすべての顧客がメインフレームLinuxに価値を見いだしたことから、メインフレームLinuxはインターネット上で公開するに至りました。

　メインフレーム用に開発したコードは、差分パッチとして1999年末にIBM developerWorks（http://www-128.ibm.com/developerworks/linux/linux390/）にて公開されました。また、LinuxのVanilla kernelには2.2.14から正式に取り込まれ、kernel2.4からは「s390」および「s390x」は標準サポートのアーキテクチャになっています。

［次回予告］ 第4回

メインフレーム・ハードウェアには、PCやUNIXサーバのハードウェアと異なる実装がいろいろとあります。例えば、メインフレームにはPUSH/POPのようなスタック命令がありません。メモリ管理やI/Oについても、その実装は特徴的です。多重処理においてもハードウェアによる支援機能によって高速化しています。そこで次回は、「メインフレームLinuxの実装（後編）」ということで、メインフレーム特有のハードウェア命令やメモリ管理、I/O処理に焦点を当てて実装方法を解説します。

3/3

Index あなたの知らないメインフレームLinuxの世界 　第3回　メインフレームLinuxの実装（前編）

Page 1 メインフレームへの移植準備 意外に簡単？ カーネルのメインフレーム対応 　 Page 2 ソースコードの変更比率は？ 稼働テストにはz/VMをフル活用 クロス開発からネイティブ開発へ Page 3 パッケージ移植はほぼスムーズに ベンチマークテストの意外な結果 そして公開へ

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