 |
|
|
Q. |
2.2.x カーネルを用いた Linux オペレーティングシステムで、Server および Proxy アプリケーションを実行するのを推奨しないのはなぜですか ? |
|
A. |
Linux コミュニティでは、マルチプロセッサのホストで clone () が呼び出された場合にメモリの内容が破壊される問題があることを確認しています。以下の文は Linux.org からの引用です。
clone/SMP の競合の問題は、主に IA32 プロセッサで発生します。この競合が発生すると、カーネルが pte(ページテーブル エントリ) を読み込んでいたり、修正している間に、プロセッサは完全にフリーズしてしまったとみなして「アクセスビット」や「ダーティビット」を更新します。「アクセスビット」の競合はマイナーな問題と考えられます。なぜなら、この現象を無視したとして、最悪のケースでも kswapd がときどき間違ったページを取得しようとする程度だからです。一方、「ダーティビット」の更新の競合は、kswapd (および他のコード) によってそのビットが不意にクリアされてしまい、データが失われる可能性があります(たとえば、kswapd がページを取得しようとして、そのページを書き出さない場合や、sync() がページを同期しない場合など)。
clone に対しては、IA32 だけでなくすべてのプロセッサにおいて、いくつかの処理を修正する必要があります。Linux のプラットフォームに依存しないコードによって、clone でページデータの更新が (更新を許可すべきでない場合に) 行われてしまうことがあります。
1. アンマップの際は、ファイルのページをディスクに書き出している間は、clone を制限する必要があります。そうしなければ、アンマップ時にいくつかの書き込みがディスクと同期しなくなります。
2. sync() の処理の際にコードが tlb/cache のフラッシュを行う頻度に注目すると、この処理は、すべてのフラッシュをまとめることにより、かなり最適化できる可能性があります。
3. IA32 SMP では、clone によって「ダーティビット」の更新が (カーネルが想定していないときに) 行われる可能性があります。これらの処理は次の場合に発生します。
a)copy_page_range への分岐
b)mremap
c) mprotect
4. Page Stealer が別のプロセスで取得している場合や、Stealer が clone の場合、「ダーティビット」はコードが参照する際に変更される可能性があるため、try_to_swap_out が競合します。
set_pte または pte_clear を呼び出す他のコードのほとんどは安全です。なぜなら、それらのコードはダーティビットを無条件に設定しているか、または pte を介したアクセス/更新は行わないためです。
|
|
|
|
|
Q. |
カーネル 2.4.18 以降を用いた Linux オペレーティングシステムで、Server および Proxy アプリケーションの実行を推奨しているのはなぜですか ? |
|
A. |
それにはいくつかの理由があります。Linux は、バージョン 2.4.x までの間に NSF のパフォーマンスがいくつか改善されてきました。それらの多くは、マルチプロセッサでのパフォーマンスに関係します。さらに RealNetworks QAチーム では、Linux 2.4.18 を使用して Server 9.0 および Proxy 9.0 のビルドを広範囲にテストしてきたため、この Linux のバージョンが、 Server または Proxy にかなりの負荷がかかる状態で使用する場合の、最適なカーネルであると自信を持っています。 |
|
|
|
|
Q. |
バージョン 2.4.18 の Linux カーネルの入手方法は? |
|
A. |
このカーネルは次のサイトから直接入手できます。
http://www.kernel.org/
ftp://ftp.kernel.org/pub/linux/kernel/v2.4/linux-2.4.18.tar.gz |
|
|
|
|
Q. |
バージョン 2.4.18 の Linux カーネルを用いた市販の Linux ディストリビューションは? |
|
A. |
RedHat 7.3 には 2.4.18 カーネルが含まれています。RedHat のリリースノートには、「2.4.18 カーネルでは、待ち時間を抑えて SMP のパフォーマンスを向上させるために、スケジューラが改善されている」と記述されています。 |
