レベル: 中級 Peter Seebach (developerworks@seebs.plethora.net), Freelance author, Plethora.net
2008年 4月 08日 ソニーの PlayStation 3 (PS3) は Linux® を実行することができます。しかし Linux を適切に実行させるためには少し調整が必要です。シリーズ最終回であるこの第 3 回では、Peter Seebach が、より小さなメモリー範囲に収まるように X11 をスリムにする方法について説明します。
第 1 回と第 2 回では、システムのランレベルやそれに関連したツールを使うことによって、Linux を実行する PS3 でのメモリーの使用量を劇的に削減し、コンパイルその他のサービスに利用できるメモリーの量を増やす方法について説明しました。今回はこれらの総まとめとして、さらに実行してみる価値のある内容を、いくつか取り上げることにします。その中には、非常に大変な作業である X11 のフットプリントを小さくするという作業も含まれています。
X11 の問題は、X11 が多くの人にとって必要なものであるということです。なぜこれが問題かというと、私の PS3 での X サーバー自体のメモリー・フットプリントは最低でも約 40MB もあり、これは単に何枚かの美しい写真のために使用するメモリーの量としては、あまりにも多すぎるからです。(そうです。私は単純なテキスト端末で UNIX® を使う方法を習いました。だからといって私を変な目で見ないでください。) そうは言っても、X11 は場合によると非常に便利であり、またグラフィックスなしで実行したのでは意味がないプログラムもあります。
X11 を別のマシンで実行する
そういうわけで、X11 は必要であるものの、PS3 には X11 を快適に実行するための十分なメモリーはありません。ここに 1 つ、ネットワーク経由で X11 を実行するという裏技があります。X クライアントを PS3 上で実行するようにし、X サーバーはリモート・システム上で実行するように構成するのです。このような構成にすると、並外れて高速というわけではなくなります。ハイパーバイザーは、ハードウェアが持つネットワーク・パフォーマンスの公称値であるギガビットから少し低下させるようです。しかし可能な限り最高速の処理を必要とするのでない限り、実際にはこの構成で十分使用に耐えるのです。この構成をセットアップするためにはいくつかの選択肢がありますが、まずは、別のマシンで X サーバーを実行する必要があります。
 |
このシリーズについて
この 3 回シリーズの記事では、開発環境という視点から PS3 Linux を調べます。
最初の記事では、第 1 回として、基本的な構成のための PS3 特有の調整項目やウィジェットを紹介し、それらを効果的に使うための方法を説明し、そしてパフォーマンスの改善や使いやすい表示を実現するための、ちょっとした細工を提言します。
第 2 回と第 3 回は、パフォーマンスとチューニングの問題をいくつか掘り下げ、そうした問題への対応はどのシステムにでもあてはまるものの、PS3 を概念検証デモから実際に動作するシステムに変える上で特に有効であることを解説します。
|
|
ところで OS X には、PS3 上で実行できるという根強い噂があります。その理由は、ある展示会で Cell/B.E. 技術による映像のデモが Mac で流されたことがあり、そのときの映像を証拠としてネットに投稿する人が後を絶たないからです。どうやら、その状況はさらに悪化しそうです。なぜなら、私は OS X マシン上でネイティブの X11 サーバーを使って、それを実証するからです。実際、X は非常に移植しやすく、基本的な方法はどこに移植する場合も同じです。
まず、X サーバーを起動してプロンプトを表示させ、任意のターミナル・プログラムを実行します。私はターミナル・プログラムには xterm を選びました。ここから先には 2 つの方法があります。1 つの方法は、X をトンネルする ssh の機能を使って X リクエストをクライアント (つまり PS3) からサーバー (この場合は Mac) に転送する方法です。もう 1 つの方法は、ネットワーク経由で X を直接使う方法です。どちらの方法にも、それぞれ長所と短所があります。ローカル・ネットワークの場合には、ネットワーク経由で X を使う方法の方が説明も使い方も簡単かもしれません。その場合はまず、X サーバーの DISPLAY が何であるかを判断します。X 端末で環境変数 DISPLAY を出力すると、おそらく「:0.0」が表示されるはずです。これは X サーバーで「:0.0」というディスプレイを実行していることを意味します。コロンはホスト名とディスプレイ名 (ディスプレイ番号およびスクリーン番号) とを分離しています。もしラップトップに「laptop」という名前が付けられていたとすると、そのディスプレイの完全な名前は「laptop:0.0」です。(名前が省略されている場合は、X は巧みな手法を使って即座にローカル・ディスプレイにアクセスします。)
|
待ってください。どちらがサーバーなのですか？
大部分のコンピューティング環境において、「サーバー」はユーザーへの直接のインターフェースを持たないプログラムであり、「クライアント」はグラフィカル・インターフェースを持つプログラムです。しかし X では、これが逆になっています。ただしこれに混乱したとしても、それほど心配する必要はありません。多くのユーザーが、最初はそれに混乱するのです。
なぜグラフィカルなプログラムが「サーバー」であり、すべての計算動作を行うプログラムが「クライアント」なのかを理解するためには、「提供されているものは何か」と自問してみます。X サーバーはグラフィカルな表示を提供しています。従ってサーバーはクライアントから受信されるリクエスト (例えば「ピクセルを描画してください」とか「ウィンドウを表示してください」など) を処理し、そしてクライアントはこれらのサービスを自由に使用するのです。
|
|
さて、ちょっと PS3 に手を伸ばして、環境変数 DISPLAY を例えば「laptop:0.0」に設定し、xterm を実行すると、この仕組みに悲劇的な欠陥があり、Permission denied が表示されることでしょう。X はデフォルトで、リモート・ホスト上の任意のクライアントをローカル・ディスプレイの上で実行することができません。これはセキュリティーのための機能ですが、当然ながらこの制限を回避する必要があります。そのために最も簡単な方法は、PS3 上のクライアントが X サーバーにアクセスできるようにする方法で、ローカル・マシン上で xhost +<machine> というコマンドを実行します (ここで、<machine> は PS3 のホスト名または IP アドレスです)。私はルーティング不可能な動的ブロックの DNS の設定で苦労したことはないので、ここでは xhost +10.10.10.134 と入力しました。これが終わると PS3 上で X コマンドを実行できるようになります。Mac 上には X コマンドが表示され、PS 3 上で X サーバーを実行することによる大きなメモリーのオーバーヘッドはありません。
X11 リクエストを転送する
さて、もう 1 つの選択肢である ssh コマンド (sshd を実行したままになっていますね？) は X11 リクエストを転送することができます。X サーバーにアクセスする際に ssh を実行する場合、-X オプションを指定すると ssh は X リクエストを転送します。実際には -Y オプションの方が適切かもしれません。-Y オプションは「信頼できる」転送が可能であるため、多くのセキュリティー機能をバイパスできるからです。(セキュリティー機能をバイパスする理由は、バイパスしないと、例えばウィンドウを開くといった操作ができないためです。) またどちらの場合も、X11 のパケットを含めてデータの圧縮を指定する -C オプションを追加することもできます。これは低速のネットワークでは便利ですが、高速のネットワークではそれほど便利ではありません。両方の方法を試して結果を見てください。そのための構文はとても容易であり ssh -X <ps3> とするだけで、この状態で PS3 では X を使用するコマンドを実行します。この方法では、PS3 にはサーバーのためのメモリーのオーバーヘッドはなく、クライアントのためのメモリーのオーバーヘッドがあるだけです。これでいよいよ konquerer を起動できるようになったのでしょうか。いや、それでもまだ konquerer はメモリーを約 20MB 使用し、さらに 7.5MB を kded 用に、5.8MB を klauncher 用に、5MB を kio_file 用に、4.7MB を kdeinit 用に使用するのです。
これによって 2 番目の問題が明らかになります。つまりサーバーなしの状態でさえ、X アプリケーションは大量のメモリーを消費します。サーバーを別マシンに置くことで利用可能なメモリーを増やすことはできますが、メモリー不足の問題を完全には解決できるわけではありません。
サーバーをスリムにする
リモート・アクセスでは速度が十分ではないかもしれず、また X サーバーは使いやすくないかもしれません。ここにもう 1 つの方法があります。サーバーをローカルで実行し、ただし KDE または Gnome を使わない方法です。このためには、おそらくランレベル 5 の X ディスプレイ・マネージャーとログイン・ウィンドウをあきらめる必要があり、コンソールを使ってログインし、自分で X を起動する必要があります。これを行う昔ながらの方法は、xinit プログラムを実行する方法です (xinit プログラムはホーム・ディレクトリーにある .xinitrc ファイルの中にあるコマンドを実行します)。これらのコマンドがシーケンシャルに実行されることに注意してください。複数のプログラムを同時に実行したい場合には、最初のいくつかのプログラムをバックグラウンドで実行する必要があります (コマンド行の最後に & を付けます)。例えば .xinitrc を次のようにします。
リスト 1. ごく単純な X サーバー
X が X の「セッション」として実行していたプログラムが終了すると、X も終了します。この場合、そのプログラムは xinitrc が最後のコマンドとして実行していた twm です。一部の人は、セッション・プログラムに xterm を使用してウィンドウ・マネージャーをバックグラウンドで実行する方法を好みます。どちらの方法を選ぶかは皆さん次第です。
この .xinit ファイルを使用して xinit を実行すると、灰色で点描された背景と、そして何と言うか、おかしな 9 面のパネルのようなマウス・カーソルが表示されるはずです。これは、配置場所に関するユーザーの指示を待っているときの xterm の表示です。twm ウィンドウ・マネージャーの最大の特徴は、小さいということです。twm は、twm 自らが判断してさまざまなことをしてくれるわけではなく、何をすればよいかはユーザーが知っているものとして基本的にユーザーが指示したとおりの動作をするのです。その代わりメモリー・フットプリントは 2MB を少し超える程度であり、Gnome や KDE などのように大きなものよりも大幅に小さくなっています。私のシステムでは、実際のところ xterm プログラムの方が twm よりも多くのメモリーを使用していますが、メモリーの大部分は X サーバーに使用されており、仮想サイズは 62MB、そして実際に RAM に常駐しているのは 34MB です。これは少し多めですが、ではどうすればよいのでしょう。
実は、できることは限られています。まず明らかに必要なのは、モジュールを無効にすることです。以前にモジュールを無効にしたことがあれば、このプロセスのことはわかるはずです。/etc/X11 に移動し、xorg.conf を編集します (このためには root 権限が必要です)。そして必要のないモジュールをコメントアウトすればよいのです。ところが xorg.conf の中にはモジュールに関する記述がありません。最近の X.org サーバーのデフォルト動作では、すべてのモジュールをロードし、何が必要かを調べます。幸い、この動作を無効にするのは簡単です。Modules セクションに必要なものを記述すると、その要求したものだけがロードされます。グラフィックス用のハードウェアが動作していないシステムでは、GL 関係のさまざまなオプションはほとんど無意味です。私の場合は最終的に次のようなものを使用しました。
リスト 2. モジュールを減らす
Section "Module"
Load "extmod"
Load "type1"
Load "freetype"
EndSection
|
残念ながら、これで実際に何かが大きく変わるわけではありません。この変更により、RAM に常駐する X サーバーは、34MB から、いや少し待ってください ・・ 33MB に減りました。真の問題はもちろん、フレームバッファー・デバイス (1280x768 など) に書き込まれる、内部バッファーが使用する大量のメモリーにあり、そしてフレームバッファーは実際に 32 ビット・モードでしか動作しません。フレームバッファーのサイズを減らすことは実際に非常に有効ですが、当然ながら表示画面が大きく犠牲になります。例えば 480p の非フルスクリーン・モード (これは 480 ピクセルよりも大幅に少なくなっています) では、X が約 10MB の実メモリーしか使っていませんでした。720p の非フルスクリーン・モードでさえ、WXGA モードで使用しているよりも少ない (25MB の) メモリーしか使いません。空きメモリーがぎりぎりの場合には、少し解像度を下げてもよいかもしれません。PS3 があまり多くの種類のビデオ・モードをサポートしていないのは残念なことです。
他の方法でメモリー使用量を削減する
メモリー使用量を削減するための方法が、もう少しあります。PS3 の複数のログイン・コンソールを使っていない場合には、使っていないログイン・コンソールをオフにします。ランレベル関係の他の機能とは異なり、これらのコンソールは実際に /etc/inittab の中で直接エンコードされます。Fedora のデフォルトの構成では、出荷時に 6 つのコンソールが有効になっていますが、私はログイン・コンソールよりもスクリーンの方が使い道があると思います。6 つのコンソールのうちの 5 つをオフするためには /etc/inittab を次のように変更します。
リスト 3. コンソールは 1 つで十分です
# Run gettys in standard runlevels
1:2345:respawn:/sbin/mingetty tty1
2:2345:off:/sbin/mingetty tty2
3:2345:off:/sbin/mingetty tty3
4:2345:off:/sbin/mingetty tty4
5:2345:off:/sbin/mingetty tty5
6:2345:off:/sbin/mingetty tty6
|
ランレベル・ファイルへの変更は新しいランレベルに変更すると認識されます。では inittab への変更はどうなのでしょう。inittab が変更されたことを init に知らせるためには、/sbin/init q を実行します。引数 q はランレベルを示すのではなく、init の構成ファイルをリロードするように init に指示します。(q は問い合わせ (query) を表すのではないかと思いますが、ドキュメンテーションには書かれていません。)
|
シェル・サイズ
bash には数多くの長所があります (多すぎて説明できないほどの機能セット、多くのものとの互換性、さまざまな標準との互換性を有するためのさまざまに異なる実行モード、等々)。しかし少量のメモリーでは bash を実行することはできません。
スクリプトを実行するために便利な、bash に代わる 1 つの選択肢 (ただし対話型のシェルとしては理想的ではありません) として、必要最低限のものだけを備えた dash があります。dash は Kenneth Almquist による (ash という) シェル・クローンのバリエーションであり、Debian メンテナーによって開発されたものです。dash の目標は、スクリプトを実行できる小規模で高速のシェルを実現することです。dash は bash のようにあらゆる機能を持っているわけではありませんが、移植可能なシェル・スクリプトのほとんどすべてを実行することができ、しかもそれらを少量のメモリーで高速に実行することができます。
私のテスト・システムでは、標準的な bash の呼び出しで最初のプロンプトを出力するまでに約 1.7MB のメモリーを使用していましたが、dash が使用したのは約 560KB でした。これは、スクリプトまたは makefile が bash の代わりに dash を使うように変更できる場合には特に便利です。残念ながら、一部のプログラムでは /bin/sh が実際に bash でないと互換性の問題が起こります。とは言え、もう少しメモリーが必要な場合には dash を使うことを検討する必要があります。
|
|
また、通常のバックグラウンド・ジョブが必要ない場合には、anacron と crond を停止することができます。ネットワーク設定をハードコーディングしても構わないのであれば、dhclient を停止することもできます。特に有望な方法として、bash を dash で置き換えられるかもしれません (「シェル・サイズ」を参照)。とは言え、これがほとんど限界です。これらの方法以外にメモリーを確保するための唯一の方法としては、基礎となっている PS3 フレームバッファーあるいはハイパーバイザーの構造を変更することですが、それは現実的ではありません。
その一方、プロンプトを表示する前に既にスワップを始めていたシステムだったものが、2、3 のシェルと top プロセス、そして sshd を実行しながら、100MB を超える空きメモリーを持つシステムにまでなったことは、決して小さな収穫ではありません。このシステムを 2GB 以上のメモリーを持つラップトップと比べて大したことないと見なすのは簡単ですが、開発プラットフォームに 100MB の空きメモリーがあれば、非常に多くのソフトウェア開発が実現可能になります。これだけのメモリーがあれば、多くのビルドをバッファー・キャッシュの中に完全に収容することができ、大きく時間を節約することができます。しかも極端な場合以外、ほとんどスワップを回避できることは言うまでもありません。
まとめ
これらの調整によって、PS3 は使用に耐える、さらには一種の余裕を持った開発環境になることができます。(PS3 は Cell Broadband Engine をいじりたいと思っている人にとっては最も利用しやすい環境の 1 つです。) コンパイルの際の応答性はよく、またコンパイルは調整前よりも目立って速く実行されるようになります。PS3 に提供されているメモリーはデスクトップ・システムには不十分かもしれませんが、ビデオ・プレーヤーと Web ブラウザー、そして E メール・クライアントをすべて同時に実行できることを考えると、開発の作業には十分適切であり、そしてもちろん、GNOME と KDE によるオーバーヘッドをなくすことで、一部のデスクトップ作業すら可能になります。PS3 のファームウェアの今後の更新によって、また新しいカーネルのバージョンやドライバーによって、さまざまなものが改善される可能性は大いにあります。システムにとって必要なものは何かに常に注意し、また使用していない機能を無効にすることを忘れないでください。
参考文献 学ぶために
製品や技術を入手するために
- 2 枚組の DVD セット、SEK for Linux をご注文ください。DB2® や Lotus®、Rational®、Tivoli®、WebSphere® など、Linux 用の最新 IBM ソフトウェアの試用版が含まれています。
- developerWorks から直接ダウンロードできる IBM trial software を利用して皆さんの次期 Linux プロジェクトを構築してください。
議論するために
著者について | 
| | Peter Seebach は長年にわたってゲーム機を収集していますが、それらの上で Linux を実行するようになったのはごく最近です。これがテレビゲームもできる Linux マシンなのか、あるいは Linux も実行できるゲーム機なのか、彼はいまだにわからずにいます。 |
記事の評価
| 
