第13章 特殊処理環境の管理

13.1.1 1次プロセッサと2次プロセッサ

マルチプロセシング・システムでは，コンソール・デバイスに論理的または物理的に付加された 1 つのプロセッサがシステム内の他のプロセッサの起動を担当します。 そのようなプロセッサを1次プロセッサと呼びます。 1次プロセッサ自身は，マルチプロセシング・システムをブートするコンソール・コマンドのターゲットとなります。 1次プロセッサは，システム全体のオペレーティング・システム環境の定義やメモリの準備のための初期化を単独で行います。 さらに，1次プロセッサはシステム内の計時を担当し，システム時間の管理，およびタイマ・キューに登録された各要素がタイムアウトになっていないかどうかの監視を行います。 一方，マルチプロセシング・システム内のこれらの役割を持たないプロセッサを2次プロセッサと呼びます。

13.1.2 アベイラブル・セットとアクティブ・セット

システムのハードウェア電源投入時の診断テストにパスしたプロセッサの集合をアベイラブル・セットと呼んでいます。 このとき，各プロセッサがシステムに対してアクティブに関与しているかどうかは問題にされません。 1次プロセッサと2次プロセッサは，マルチプロセシング・システムのアクティブ・セットから構成されます。

アクティブ・セットとは，VAX システム，Alpha システム，または I64 システムを構成するプロセッサのうち，電源投入時の診断テストにパスし，システム動作にアクティブに関与しているプロセッサの集合をいいます。 オペレーティング・システムはこれらのセットに含まれる各プロセッサを CPU ID で識別します。 CPU ID の値は，DCL やユーティリティの特定のコマンドの構文や表示の中に頻繁に現れます。

13.1.3 プロセッサの機能

マルチプロセシング・システムはシステム上で実行中のプロセスに特定の機能を提供します。 次の機能がサポートされています。

さらに，他の機能を追加したり，削除したりするメカニズムもあります。

実行機能は，CPU の開始動作と停止動作に影響します。

13.2.1 マルチプロセシング環境の作成

マルチプロセシング・システムの構成要素と特性は，適切なシステム・パラメータを設定することによって，システムのブート時に制御できます。 マルチプロセシング・システムを管理するシステム・パラメータには以下のものがあります。

以上のようなシステム・パラメータについては，『OpenVMS システム管理 ユーティリティ・リファレンス・マニュアル』を参照してください。

ブート時に，アベイラブル・セットの中のプロセッサをアクティブ・セットに追加することができます。 また，DCL の START/CPU コマンドを使用すれば，ブート後にプロセッサの追加を行うことができます。 アクティブ・セットからプロセッサを削除するときには，DCL の STOP/CPU コマンドを使用します。

SMP Extension License

Alpha システムおよび I64 システムでは，SMP システムを使用している場合には，SMP Extension Licenseを登録する必要があります。 このライセンスは Operating System Base License および全 Interactive User ライセンスをアップグレードして，システムのマルチプロセシング・レベルに合わせます。

SMP Extension License は，既存の Base ライセンスおよび User ライセンスがユニプロセシング・レベルで提供するすべての権利を付与するので，マルチプロセシング・システムにアップグレードする際に，これらのライセンスを再インストールする必要はありません。 システムを新しいマルチプロセシング・レベルにアップグレードする場合には，既存のライセンスに SMP Extension License を追加してください。

13.2.2 マルチプロセシング環境の監視

オペレーティング・システムのいくつかの機能により，マルチプロセッサ・システムの特性，能力，および状態に関する特別な情報を入手することができます。 これらを可能にするものには，DCL の SHOW CPU コマンド，MONITOR ユーティリティなどがあります。

マルチプロセッサ構成に関する情報の入手

SHOW CPU コマンドにより，マルチプロセシング・システムの構成および状態を示す 3 つのレベルの情報が表示されます。

SMP に関連する DCL のコマンドについては，『OpenVMS DCL ディクショナリ』を参照してください。 MONITOR ユーティリティについては，『OpenVMS システム管理 ユーティリティ・リファレンス・マニュアル』の MONITOR のパートを参照してください。

13.3.1 VAX におけるベクタ処理のサポート (VAX のみ)

VAX ベクタ・アーキテクチャには，それぞれが 64 個の要素を含む 16 個の 64 ビット・ベクタ・レジスタ (V0 ～ V15)，ベクタ・カウント・レジスタ (VCR) やベクタ長レジスタ (VLR)，ベクタ・マスク・レジスタ (VMR) などのベクタ制御レジスタ，ベクタ機能ユニット，ベクタ命令のセットが含まれています。 VAX ベクタ命令は，ベクタ・レジスタとメモリとの間のデータ転送，整数および浮動小数点数の算術演算，およびプロセッサの制御を行います。 VAX ベクタ・アーキテクチャ，ベクタ・レジスタ，およびベクタ命令についての詳細は，『VAX MACRO and Instruction Set Reference Manual』 を参照してください。

VAX ベクタ・アーキテクチャに準拠した VAX システムをベクタ対応システムと呼びます。

VAX ベクタ処理システムの構成には，スカラ CPU とベクタ CPU とを統合したプロセッサ (ベクタ機能付きプロセッサ) が 1 組以上含まれています。 このようなシステム構成には，各スカラ・プロセッサに対して 1 つのベクタ・コプロセッサを持つ対称型構成，および付加的なスカラ専用プロセッサを組み込んだ非対称型構成があります。 VAX ベクタ処理システムのモデルにより，ベクタ機能付きプロセッサは，スカラ CPU コンポーネントとベクタ CPU コンポーネントを物理的に統合した単一のモジュールから構成される場合と，それぞれのコンポーネントを物理的に分離した 2 つのモジュールから構成される場合があります。 どちらの場合も，スカラ CPU および ベクタ CPU は論理的に統合され，同じメモリを共用し，高速の専用内部パスを通じてデータを送信します。 このように CPU が密接に結合しているため，ベクタ CPU を使用した場合は入出力動作が軽減されます。

VAX スカラ処理システムと同様，VAX ベクタ処理システムは VAXcluster のメンバ，ネットワーク上のノード，またはスタンドアロン・システムとして稼働させることができます。

13.3.2 VAX ベクタ命令エミュレーション機能 (VVIEF) (VAX のみ)

VAX ベクタ命令エミュレーション機能 (VVIEF) は，オペレーティング・システムに標準で備えられている機能であり，ベクタ・プロセッサが利用できない VAX システム上でベクタ化されたアプリケーションの作成やデバッグを可能にします。 VVIEF は，非特権 VAX ベクタ命令とベクタ・システム・サービスを含む VAX ベクタ処理環境をエミュレートします。 VVIEF の使用は，ユーザ・モードのコードに制限されています。

VVIEF は厳密にプログラム開発ツールであり，ベクタ・ハードウェア上での動作をソフトウェア上で実現するものではありません。 したがって，VVIEF のもとで実行するようにアプリケーションをベクタ化しても性能は向上しません。 むしろ，VVIEF のもとで実行されるベクタ化アプリケーションの動作はスカラ版アプリケーションよりも低速です。

オペレーティング・システムは，VVIEF ブートストラップ・コードをエグゼクティブ・ローダブル・イメージとして提供します。 ここで注意が必要なのは，OpenVMS ベクタ・サポート・コードが存在すると，VVIEF は非稼働状態のままであるという点です。 ベクタ機能付きシステムでベクタ・サポート・コードをロードしないようにして VVIEF を稼働させることは可能ですが，それによる利点はほとんどありません。 ベクタ・サポート・コードのロードについては，13.4.1 項 「ベクタ処理サポート・コードのロード (VAX のみ)」 で説明します。

VVIEF のロードとアンロードについては，13.4.6 項 「VAX ベクタ命令エミュレーション機能 (VVIEF) のロード (VAX のみ)」 で説明します。

13.4.1 ベクタ処理サポート・コードのロード (VAX のみ)

VAX ベクタ処理システムでは，ブート時にベクタ処理サポート・コードが自動的にロードされるように設定されています。 この省略時の動作は，静的なシステム・パラメータ VECTOR_PROC を設定することで変更することができます。 具体的な設定方法は，表 13-1 「システム・パラメータ VECTOR_PROC の設定」 に示すとおりです。

13.4.2 ベクタ処理システムの構成 (VAX のみ)

マルチプロセシング構成へのベクタ機能付きプロセッサの追加または削除は，システム・パラメータ SMP_CPUS を設定することによってブート時に行うことができます。 また，DCL の START/CPU コマンドおよび STOP/CPU コマンドによって実行時に行うこともできます。 オペレーティング・システムはベクタ機能付きプロセッサのスカラ CPU コンポーネントとベクタ CPU コンポーネントとを単一のプロセッサとして扱い，これらの起動と停止を同時に行います。

ブート時，システム・パラメータ SMP_CPUS の設定に従って，マルチプロセシング・システムの中の2次プロセッサのうちどのプロセッサを構成に追加するかが決定されます。 これらの2次プロセッサの中にはベクタ機能付きプロセッサも含まれます。 オペレーティング・システムは，1次プロセッサを常に構成に追加します。 システム・パラメータ SMP_CPUS の省略時の値 –1 では，利用可能なすべてのプロセッサがブートされ，スカラ・プロセッサもベクタ機能付きプロセッサも同様にシステム構成に追加されます。 この SMP_CPUS パラメータについての詳細は，『OpenVMS システム管理 ユーティリティ・リファレンス・マニュアル』を参照してください。 ブート時，ベクタ機能付きプロセッサの起動の前に，ベクタ処理サポート・コード (13.4.1 項 「ベクタ処理サポート・コードのロード (VAX のみ)」 を参照) をロードしておく必要があります。 サポート・コードがロードされていなければ，プロセスはベクタ機能付きプロセッサのスカラ CPU コンポーネントしか使用できなくなります。

稼働中のマルチプロセシング・システムに2次プロセッサを追加する場合は，DCL の START/CPU コマンドを使用します。 また，システムから2次プロセッサを削除する場合は，STOP/CPU コマンドを使用します。 この場合でも，ベクタ処理サポート・コードがブート時にロードされていなければ，起動したベクタ機能付きプロセッサのベクタ CPU コンポーネントを使用することはできません。

STOP/CPU コマンドを使用する場合，そのコマンドによって削除するベクタ機能付きプロセッサが現在動作中のベクタ使用プロセスにベクタ機能を提供する唯一のものである場合，コマンドは異常終了し，メッセージが生成されます。 プロセッサを修理するためにプロセッサを構成から削除するような特別なケースでは，STOP/CPU/OVERRIDE コマンドを発行すれば，ベクタ機能を使用するプロセスが残っていてもプロセッサを強制的に停止させることができます。

STOP/CPU/OVERRIDE コマンドがベクタ機能付きプロセッサに対して発行された場合，またはベクタ機能付きプロセッサが異常終了した場合，オペレーティング・システムは残されたすべてのベクタ使用プロセスをベクタ機能付きプロセッサが構成に追加されるまで「CPU 機能待ち」状態 (RSN$_CPUCAP) にします。 その後，他のプロセス (潜在的ベクタ使用プロセス) からベクタ命令が発行されると，要求された CPU が稼働していないことを示すメッセージ (CPUNOTACT) が返されます。

START/CPU コマンドと STOP/CPU コマンドについての詳細は，『OpenVMS DCL ディクショナリ』を参照してください。

13.4.3 ベクタ・プロセスの管理 (VAX のみ)

オペレーティング・システムのスケジューリング・アルゴリズムにより，ベクタ処理資源とスカラ処理資源とはベクタ使用プロセス，潜在的ベクタ使用プロセス，スカラ使用プロセスに自動的に分配されます。 しかし，VAX ベクタ処理構成は，次の 2 つの重要な点が異なります。

システム内に存在するベクタ使用プロセスの数がそれらにサービスを提供するスカラ機能付きプロセッサ (スカラ・プロセッサとベクタ・プロセッサのペア) の数よりも多い場合は，プロセスの優先順位に従ってベクタ使用プロセスがベクタ機能付きプロセッサを共用します。 ベクタ機能付きプロセッサを使用する複数のプロセスの優先順位が等しい場合，それらのプロセスはラウンド・ロビン形式でスケジューリングされます。 ベクタ機能付きプロセッサに新しいベクタ使用プロセスをスケジューリングする場合，システムは現在メモリ内に存在するベクタ使用プロセスのベクタ・コンテキストを保存し，メモリから新しいベクタ使用プロセスを復元する必要があります。 このような「低速」ベクタ・コンテキスト・スイッチが過剰に発生する場合は，実際の演算よりもベクタ・コンテキスト・スイッチに多くの処理時間が費やされるようになります。

ベクタ処理の必要性が大きなシステムは，それらの必要性を満たすように構成する必要があります。 しかし，既存の構成のままでチューニングを行うことでその性能を改善できるいくつかの方法があります。

13.4.4 ACL によるベクタ・プロセッサへのアクセスの制限 (VAX のみ)

ベクタ 機能は，ユーザがベクタ・プロセッサのサービスを使用できるようにするために，オペレーティング・システムが使用する抽象的なソフトウェアです。 アクセス制御リスト (ACL) にベクタ機能のオブジェクトを対応づけることによって，ベクタ・プロセッサの使用を特定の ID を持つユーザに制限することができます。

たとえば，大学ではベクタ・プロセッサの使用を，イメージ処理を研究する学部や学生に限定する場合があります。 また，情報サービス会社では，ベクタ機能へのアクセスとベクタ・プロセッサを使用した時間の一方または両方をユーザに対して請求する場合があります。

DCLコマンド SET SECURITY/ACL を次の形式で使用して，ベクタ機能についての ACL を設定します。

次の DCL コマンドでベクタ機能のが表示されます。

$ SHOW SECURITY /CLASS=CAPABILITY VECTOR

ここで，ACL はベクタ機能に対して設定されるものであり，システム上の任意またはすべてのベクタ機能付きプロセッサの使用を制限するものではないということに注意してください。 オペレーティング・システムは，ベクタ機能付きプロセッサ上のベクタ機能を使用する許可を持たないプロセスでもスケジューリングします。 しかし，これらのプロセスが利用できるのはプロセッサのスカラ CPU コンポーネントだけであって，ベクタ命令を実行することはできません。 同様に，ACL はベクタ機能に対して設定され，ベクタ機能付きプロセッサに対して設定されているものでないため，ACL を使って特定のプロセッサ上でジョブを長時間実行させることはできません。

SET SECURITY コマンドと SHOW SECURITY コマンドについての詳細は，『OpenVMS DCL ディクショナリ』を参照してください。

13.4.5 ベクタ処理システムに関する情報の入手 (VAX のみ)

ベクタ処理システムの状態とプロセス別のシステム使用量についての情報をさまざまな方法で入手することができます。 具体的には，次のとおりです。

13.4.6 VAX ベクタ命令エミュレーション機能 (VVIEF) のロード (VAX のみ)

VAX ベクタ命令エミュレーション機能 (VVIEF) は，オペレーティング・システムに標準で備えられている機能であり，ベクタ・プロセッサが利用できない VAX システム上でベクタ化されたアプリケーションの作成やデバッグを可能にします。 VVIEF は厳密にプログラム開発ツールとして意図されたものであり，ベクタ・ハードウェア上での動作をソフトウェア上で実現するものではありません。 したがって，VVIEF のもとで実行するようにアプリケーションをベクタ化しても性能は向上しません。 むしろ，VVIEF のもとで実行されるベクタ化アプリケーションの動作はスカラ版アプリケーションよりも低速です。

コマンド・プロシージャ SYS$UPDATE:VVIEF$INSTAL.COM を呼び出すと，次回以降のシステム・ブート時に VVIEF がロードされます。 VVIEF をアンロードするためには，コマンド・プロシージャ SYS$UPDATE:VVIEF$DEINSTAL.COM を呼び出して，システムをリブートします。

システムに VVIEF が存在するかどうかは DCL の以下のコマンドによって調べることができます。

$ X = F$GETSYI("VECTOR_EMULATOR") 
$ SHOW SYMBOL X
X = 1   Hex = 00000001  Octal = 0000000001

戻り値が 1 の場合はVVIEF が存在し，0 の場合は存在しません。

ベクタ・サポート・コードが存在してもVVIEF をシステムにロードすることはできますが，その場合は非稼働状態のままになります。 ベクタ機能付きシステム (13.4.1 項 「ベクタ処理サポート・コードのロード (VAX のみ)」を参照) でベクタ・サポート・コードをロードしないようにして VVIEF を稼働させることは可能ですが，それによる利点はほとんどありません。 システム内でベクタ機能付きプロセッサだけに障害が発生した場合，中断されたベクタ化されたアプリケーションの実行は VVIEF のもとでは再開されません。