JP3591883B2 - 計算機及びそのシステム及びその制御方法 - Google Patents

Description

【０００１】
【産業上の利用分野】
本発明は計算機及び計算機システム及びその制御方法に関するものであり、通信媒体を介して接続し、それぞれのメモリを互いに利用することが可能な計算機及びそのシステム及びその制御方法に関するものである。
【０００２】
【従来の技術】
主に複数台の計算機が高速な通信回線で結合され、各計算機に配置されたメモリ（またはその一部）が全体で単一のメモリ空間を構成し、システム全体でＮＵＭＡ（ＮＯＮＵＮＩＦＯＲＭ ＭＥＭＯＲＹ ＡＣＣＥＳＳ）型のマルチプロセッサシステムの様な形態で動作可能な情報処理装置がある。つまり、ある計算機から見て自計算機に配置されたメモリのアクセスは高速で、他の計算機に配置されたメモリへのアクセスは速度が落ちるが、全体で単一のメモリ空間を成すためマルチプロセッサシステムとしてもとらえることができる形態である。
【０００３】
従来、ＬＡＮなどの低速な通信回線で結ばれた計算機システムの場合、ユーザプログラムをプロセスとして生成、起動する際、物理メモリの一部を確保し、動作させている。近年では、仮想記憶機構を持つＯＳ（オペレーティングシステム）が登場し、確保しようとする物理メモリが不足している場合であっても、使用率の低い物理ページの内容を自計算機に付随する二次記憶装置または他の計算機などにページアウトすることで自計算機上に物理ページを確保することも行っている。
【０００４】
しかしながら、かかる仮想記憶機構を持つＯＳであっても、たとえ通信回線で結ばれた他の計算機上の物理メモリが空いていて、それを間接的に利用することはできても直接利用することはできなかった。これは、通信回線が低速であったため、他の計算機の物理メモリを直接見せるようなハードウェア構成をとれなかったためである。
【０００５】
ところが、光ケーブルなど、信頼性もあり計算機の内部バスにある程度近い性能を持つ通信媒体が登場してきた。これによれば、物理メモリを直接他の計算機に見せるような構成も可能となり、各計算機に配置されたメモリを（またはその一部を）全体で単一のメモリ空間として、どの計算機からでも直接アクセス可能にすることができるようなシステムが提案されてきている。このようなシステムの場合、上記のようなページアウトを行わなくても他の計算機上のメモリが空いていれば、それを確保し直接利用することが可能となる（こうしたページをリモートページと呼ぶ）。
【０００６】
【発明が解決しようとする課題】
しかしながら、プロセスを生成しようとした計算機上の物理メモリが不足していた時、上記のように他の計算機のページを確保する際、なんの規則性も持たず複数台の計算機から闇雲にリモートページを確保していくと、プロセスの実行に必要となるページが複数台の計算機に分散配置され、このような状態のままプロセスが実行し続けると、システムの処理効率が低下してしまうという問題点が予想される。
【０００７】
これは、上記光ケーブルが高速になったといっても、それ以前の通信媒体にたいするものであり、プロセッサとそのプロセッサが使用する物理メモリが同一計算機上の場合と比較した場合にははるかにメモリアクセスが遅いからである。尚、他計算機上のメモリを自計算機のプロセッサがアクセスすることを、リモートアクセスと呼ぶ。
【０００８】
そこで、本願出願人は、上記の問題点を解消するため、以下の提案をしている。すなわち、
プロセスが生成、起動され物理ページを確保していく際、プロセスが動作している計算機上にページが確保できなくなると、他の計算機上から確保しようと試みるが、この時複数台の計算機からばらばらに確保していくのではなく、できるだけ一つの計算機上から確保していくようにする。そして、該プロセスを現在のままのプロセッサで実行させ続けた方が効率がいいか、または他の計算機上に設置されているプロセッサの管理のみを移動して来て、そのプロセッサで実行させた方が効率がいいかを判断し、もし後者であると判断した場合には、効率のよいと判断されたプロセッサの管理を移動してきて該プロセスの実行に割り当てる。この結果、プロセス処理効率を向上できる計算機システムを構築することが可能になる。尚、この時、管理を移動してきたプロセッサをリモートプロセッサと呼ぶことにする。
【０００９】
しかし、このようにリモートページ、そしてリモートプロセッサをプロセスの実行に割り当てると、そのプロセス自体の実行効率は良くなるものの、もし、プロセスがシステムコールを発行し、ＯＳに制御が移ると、ＯＳ内部の実行は効率が落ちることになる。なぜなら、ＯＳのプログラムコードは自計算機上のメモリに存在しているため、他計算機から管理を移動してきたリモートプロセッサがそのままＯＳのコードを実行しようとするとリモートメモリアクセスになるためである。
【００１０】
【課題を解決するための手段】及び【作用】
本発明はかかる問題点に鑑みなされたものであり、複数の計算機が所定の通信媒体で接続され、それぞれのメモリが互いに利用することが可能な計算機あるいはシステムにおいて、それらシステムのいずれかの計算機で動作しているプロセスがシステムコールを発行した際に、そのシステムコールによる処理を最適なプロセッサでもって実行し、処理を高速に行うことを可能にする計算機及びシステム及び制御方法を提供しようとするものである。
【００１１】
この課題を解決するため、例えば本発明の計算機は以下の構成を備える。すなわち、
自計算機が所定の通信媒体を介して他の計算機と接続され、自計算機及び他の計算機のメモリを互いにアクセスすることが可能な計算機であって、
計算機上で動作中のプロセスから自計算機のＯＳ（オペレーティングシステム）にシステムコールがあった場合、当該システムコールの発行元のプロセッサが自計算機のプロセッサか、他計算機のプロセッサかを判定する判定手段と、
該判定手段でもって、他計算機上のプロセッサからのシステムコールであると判定した場合、当該システムコールに対する処理を行うプロセッサとして、自計算機及び前記他計算機のプロセッサの中から選定する選定手段と、
選定されたプロセッサに切換え、自計算機のＯＳのシステムコール処理を行う切換手段とを備える。
【００１２】
ここで、本発明の好適な実施態様によれば、前記判定手段は、個々のプロセッサ固有の情報を獲得する処理を実行することによって判定することが望ましい。これによって、個々のプロセッサを識別可能になるので、システムコールの発行元を判定できる。
【００１３】
また、前記選定手段は、自計算機のプロセッサを優先して選定することが望ましい。これによって、システムコールの処理自身は、それに最も近いプロセッサとメモリを使用し、通信媒体を介さずに行うので処理を高速化できる。
【００１４】
また、前記選定手段は、更に、自計算機のプロセッサの負荷が所定以上あると判断した場合、前記他計算機のプロセッサを選定する。これにより、自計算機のプロセッサに一律に切り替わるのではなく、その負荷がおおきい場合には他計算機のプロセッサを使用するので、システム全体の速度低下を防ぐことが可能になる。
【００１５】
【実施例】
以下、添付図面に従って本発明に係る実施例を詳細に説明する。
【００１６】
図１は本発明の一実施例を示す計算機システムの構成を説明するブロック図である。
【００１７】
図において、１０１は光ネットワークなどの高速な通信回線、２０１、３０１、４０１は通信回線１０１で結ばれた複数台の計算機である。２０２、３０２、３０３、４０２、４０３は前記計算機２０１、３０１、４０１に各々一つ以上備えられたＭＭＵ（メモリマネイジメントユニット）内蔵のプロセッサ（ＣＰＵ）、２１０、４１０は前記計算機２０１、４０１に備えられたユーザインターフェースとしてのディスプレイ＆キーボードである。２２０、３２０は前記計算機２０１、３０１に備えられたハードディスク（ＨＤ）装置などの二次記憶装置である。
【００１８】
ディスプレイ＆キーボード２１０、４１０や二次記憶装置２２０、３２０は計算機に装備されていなくても構わない。例えばディスプレイ＆キーボードが装備されていない計算機３０１などはサーバマシンまたはプロセッサプールとして利用されることになる。
【００１９】
１０２は、各計算機上で動作するＯＳ（オペレーティングシステム）間での非同期な通信を行うためのＣＰＵ間割込機構である。
【００２０】
２３０、３３０、４３０は全体でひとつの単一なメモリ空間を成す物理メモリ（個々の計算器で連続する必要はないが、アドレス空間が重ならないメモリ）、２４０、３４０、４４０は各計算機用のローカルメモリである。ローカルメモリは主にＯＳなどのために必要となるが、物理メモリ２３０、３３０、４３０の一部で代用可能であるため、あってもなくても本発明の実施例の適用の妨げとはならない。
【００２１】
各プロセッサは物理メモリ２３０、３３０、４３０をアクセス可能に構成されている。ただし、メモリアクセスを行うプロセッサと同一計算機内部の物理メモリへのアクセスよりも、他の計算機に属する物理メモリのアクセスの方が、通信回線１０１が介在するため遅くなる。
【００２２】
なお、本実施例において、ＯＳ２５０、３５０、４５０は、複数プロセッサのスケジューリング、仮想記憶管理などを行い、当然どの計算機上の物理メモリがどの物理アドレスになっているか、といったシステム情報を把握しているものとする。このようなＯＳは、ほぼ同様の機能を持ったものが各計算機上でそれぞれ動作し、互いに協調的に働くような構成を取る。これによって、各計算機の独立性が向上し、システム全体の柔軟性も向上する。
【００２３】
各ＯＳは各計算機上のローカルメモリ２４０、３４０、４４０上で動作しても、物理メモリ２３０、３３０、４３０上で動作しても構わない。
【００２４】
ただし、ＯＳのデータ領域の一部は、各ＯＳが管理するメモリ管理の情報やプロセスのスケジューリング情報を交換可能にするため、物理メモリ２３０、３３０、４３０上の情報交換領域に配置しておく。
【００２５】
また、ＯＳは自計算機に付随する２次記憶装置からだけでなく、他の計算機に付随する２次記憶装置からも同様に、通信回線１０１を介してユーザプログラムのローディングができるように構成されている。
【００２６】
以下、図２に示すフローチャートを参照しながら、本発明に係る計算機システムにおけるシステムコール実行動作について説明する。
【００２７】
図２は本発明に係る計算機システムに於けるシステムコール実行手順の一例を示すフローチャートである。以下、計算機２０１上でプロセスが起動された場合を例とする。尚、かかる手順（プログラム）は、各計算機のＯＳ部分に設けられているものである。
【００２８】
図１に示すようなシステムにおいて、ユーザプログラムがプロセスとして起動され、例えば計算機２０１上のプロセッサ２０２でプロセスが動作を開始したとする（ステップＳ１）。このプロセスが実行を進めていくうちにステップＳ２の様に、計算機２０１上のページが不足し、計算機３０１のリモートページを利用する様になり、かつ計算機３０１のプロセッサ３０３の管理がＯＳ３５０からＯＳ２５０に移動され上記プロセスに割り当てられた場合を考える。
【００２９】
つまり、最初は計算機２０１上のメモリで動作していたプロセスが、そのメモリ不足に陥り、計算機３０１上のメモリを利用するようになり、計算機３０１上の、例えばプロセッサ３０３の管理が計算機２０１のＯＳ２５０に移動した場合である。
【００３０】
このような、状況で、ステップＳ３のように、そのプロセスがシステムコールを発行し、ＯＳ２５０の機能を呼び出したとする。ここで、注目する点は、このシステムコールを発行したプロセッサ（ＣＰＵ）は、計算機２０１内のＣＰＵ２０２の場合と、計算機３０１内のＣＰＵ３０３（勿論ＣＰＵ３０２でも構わない）の場合の２通り考えられる点である。以下、前者をローカルプロセッサ、後者をリモートプロセッサという。
【００３１】
ステップＳ４においてＯＳ２５０は、呼び出しプロセッサ判断手段により、ＯＳ２５０を呼び出したプロセッサが、自計算機（計算機２０１）のローカルプロセッサなのか、他計算機から管理を移動してきたリモートプロセッサなのかを判断する。
【００３２】
この判断は次のように行ってもよい。例えば、自ＯＳの管理下にある全てのプロセッサに一意に識別できる管理番号を付けておき、またそのプロセッサがもともと自計算機上のローカルプロセッサなのか、それとも他計算機から管理を移動してきたリモートプロセッサなのかを区別可能な識別情報を記憶しておく。そして、いつでも自プロセッサの管理番号がいくつなのか、またそれを元に自プロセッサがローカルプロセッサなのかリモートプロセッサなのか判断できるようにしておけばよい。
【００３３】
例えば、システムコールを受けた場合、その初期段階で、そのプロセッサ識別情報を獲得する処理を実行し、それでもって判断しても良いであろう。
【００３４】
いずれにしても、後述するステップＳ６、ステップＳ９の判断の為に、呼び出しプロセッサの管理番号等を、システムコールを行ったプロセスのプロセス管理ブロックに格納しておく。
【００３５】
さて、システムコールを行ったプロセッサがローカルプロセッサであると判断した場合、つまり、計算機２０１のＯＳ２５０のシステムコールを発行したプロセッサがＣＰＵ２０２であると判断した場合、処理はステップＳ８に進み、従来通り、そのプロセッサのままシステムコールで指定された各ＯＳ内部処理を実行する。
【００３６】
また、リモートプロセッサからのシステムコールを受けたと判断した場合、つまり、計算機３０１のＣＰＵ３０３がＯＳ２５０のシステムコールを行ったと判断した場合、処理はステップＳ４からステップＳ５に進み、実行プロセッサ選定手段により、指定のＯＳ内部処理をどのプロセッサで実行したらよいのかを選定する。この選定方法は以下の様なものが考えられる。
【００３７】
もっとも簡単な方法としては、自計算機上のローカルプロセッサ（リモートアクセスでなくなるので効率が高い）でかつ自ＯＳの管理下にあるプロセッサの中からランダムに一つ選択する。別の方式としては、上記の条件に合う複数のプロセッサの中から、ランダムにではなく、もっとも負荷の少ない一つのプロセッサを選択する方法も考えられる。負荷を調べる方法としては、それぞれのプロセッサで実行予定（Ｒｅａｄｙ状態）のプロセッサ数を数え、その値がもっとも少ないものを不可の少ないプロセッサと考える事ができる。ここでは、ＯＳ２５０を考えており、動作するプロセッサはＣＰＵ２０２の１つであるので、無条件にＣＰＵ２０２が選定されることになる。但し、着目しているＯＳがＯＳ３５０の場合には、ローカルプロセッサは２つあるので、上記のいずれかの基準で選定することになる。
【００３８】
また、自計算機上のローカルプロセッサでかつ自ＯＳの管理下にあるという条件に合うプロセッサがすべて負荷が大きいような場合には、無理にこの条件にあったローカルプロセッサに切り替えるより、呼び出しプロセッサ（リモートプロセッサ）のままＯＳ内部処理を実行した方が効率がよいことも考えられる。なぜなら、プロセッサの負荷が大きいと、他の実行中のプロセスのタイムクオンタムが切れるまでプロセッサの切り替えが行われなかったり、また切り替わったとしても、スケジューリング方法によっては、ＯＳ内部処理実行中にも、他の実行予定プロセスにプロセッサを横取りされてしまったりすることも考えられるからである。
【００３９】
このような場合には、呼び出しプロセッサをそのまま選定する方がよい。この判断は、ある経験的なしきい値より負荷値が大きいかどうかの比較により行う事ができる。経験的なしきい値は、予め、リモートプロセッサのままＯＳ内部処理を実行した場合の処理時間を計測しておき、また負荷値をいくつか変化させた状態でローカルプロセッサでＯＳ内部処理を実行した場合の処理時間も計測しておく。そして、ローカルプロセッサでの処理時間が、リモートプロセッサのままの処理時間より大きくなってしまうときの負荷値をしきい値とすることができる。また、ＯＳ内部処理は複数種類あるため、それぞれの処理によってしきい値が違うことも考えられるので、その場合は、各ＯＳ内部処理ごとに異なるしきい値を決定し、設定しても構わない。この場合には、より細かい基準で選定できるので、システム全体のパフォーマンスを最大限に向上させることが可能になる。
【００４０】
さて、ステップＳ５において、実行するプロセッサ（ＣＰＵ）が選定されると、ステップＳ６に進み、選定されたプロセッサが元の呼出しプロセッサと同じプロセッサかどうか判定し、呼出しプロセッサと同じだった場合、つまり上記の例だとプロセッサ３０３だった場合には、ステップ８に進み、異なるプロセッサだった場合にはステップ７に進む。
【００４１】
ステップ７では、実行プロセッサ切り替え手段により、選定されたプロセッサに実行を切り替え、それ以降の処理が選定され切り替えられたプロセッサで実行されるようにする。例えば、実行プロセッサ選定手段によりプロセッサ２０２が選定された場合には、プロセッサ２０２に切り替わり、以降の処理がプロセッサ２０２で実行されることになる。
【００４２】
実行プロセッサの切り替えは次のようにして行ってもよい。各プロセッサ毎にそれぞれのプロセッサで実行予定のプロセスを管理するキューを持ち、キューには各プロセスを管理する（コンテキスト情報等を格納する）プロセス管理ブロックがつながれ、各プロセッサは自分のキューからプロセスを一つ選び実行していくものとする。キューからの選択は、タイムスライスでラウンドロビン的に行うのが一般的で、プロセスに優先度を持たせ優先度ごとにキューを持つようにしても構わない。
【００４３】
このようなシステムにおける、実行プロセッサの切り替えを、プロセッサ３０３からプロセッサ２０２への切り替えを例に説明する。先ず、今まで実行していたプロセッサ３０３のコンテキスト（レジスタ値など）をプロセス管理ブロックに退避し、そのプロセス管理ブロックをプロセッサ２０２のキューにつなぎかえる。その後、つなぎかえられたプロセスは、プロセッサ２０２により前述のような選択方法で選択、実行され、実行プロセッサの切り替えが終了となる。一方、プロセッサ３０３は、自分のキューに他のプロセスがつながっている場合にはそのプロセスを割り当て実行させ、ない場合にはアイドル状態になる。
【００４４】
プロセッサの切り替えが終了すると、ステップＳ８に進み、システムコールの指定に従ったＯＳ内部処理を実行する。ＯＳ内部処理が終了すると、ステップＳ９に進み、プロセッサをもとの呼出しプロセッサに切り替えるかどうかを判断する。ステップ７に進み実行プロセッサを切り替えていた場合には、もとの呼出しプロセッサに切り替える必要があると判断してステップＳ１０に進み、実行プロセッサの切り替えを行っていなかった場合には、呼出しプロセッサへの切り替えが必要がないと判断してステップＳ１１に進む。この判断は、あらかじめステップＳ４の段階でプロセス管理ブロックに格納してあった呼出しプロセッサのプロセッサ管理番号と、現在実行中のプロセッサの管理番号とを比較すればよい。
【００４５】
次にステップＳ１０では、前述の実行プロセッサ切り替え手段により、もとの呼出しプロセッサに切り替えを行う。
【００４６】
最後に、ステップＳ１１において、システムコールを発行したプロセスにリターン処理を行い、プロセスとして実行されるユーザプログラムに制御が戻ることになる。
【００４７】
以上説明したように、本実施例によれば、生成、起動されたプロセスが、リモートメモリ、リモートプロセッサを利用して動作してシステムコールを行った場合、先ず呼出しプロセッサ判断手段によりシステムコールを行ったプロセッサがローカルプロセッサかリモートプロセッサであるかが判断される。リモートプロセッサであると判断された場合には、次に、実行プロセッサ選定手段によりＯＳ内部処理を行う実行効率の高いプロセッサが選ばれ、実行プロセッサ切り替え手段により選定されたプロセッサに切り替えられ、切り替え後のプロセッサによりＯＳ内部処理が実行される。そして、ＯＳ内部処理終了後再び、実行プロセッサ切り替え手段によりもとの呼出しプロセッサに切り替えられ、システムコールを行ったプロセスに制御が戻ることになる。以上により、リモートメモリ、リモートプロセッサを利用して動作するプロセスのシステムコール処理においても、高い処理効率を得ることができるという効果を奏する。
【００４８】
尚、本発明は、システム或は装置にプログラムを供給することによって、実現及び達成される場合にも適用できることはいうまでもない。
【００４９】
【発明の効果】
以上説明したように本発明によれば、複数の計算機が所定の通信媒体で接続され、それぞれのメモリが互いに利用することが可能な計算機あるいはシステムにおいて、それらシステムのいずれかの計算機で動作しているプロセスがシステムコールを発行した際に、そのシステムコールによる処理を最適なプロセッサでもって実行し、処理を高速に行うことが可能になる。
【００５０】
【図面の簡単な説明】
【図１】実施例を示す計算機システムの構成を説明するブロック図である。
【図２】実施例における計算機システムにおけるシステムコール実行手順の一例を示すフローチャートである。
【符号の説明】
１０１ 高速な通信回線
１０２ ＣＰＵ間割込機構
２０１，３０１，４０１ 通信回線１０１で結ばれた複数台の計算機
２０２，３０２，３０３，４０２，４０３ 各計算機に一つ以上備えられたＭＭＵ内蔵プロセッサ
２１０，４１０ ディスプレイ＆キーボード
２２０，３２０ ハードディスク装置などの二次記憶装置
２３０，３３０，４３０ 全体で単一なメモリ空間をなす物理メモリ
２４０，３４０，４４０ 各計算機上のローカルメモリ
２５０，３５０，４５０ 各計算機上で動作するＯＳ
２６０，３６０，４６０ 情報交換領域

Claims (16)

1. 自計算機が所定の通信媒体を介して他の計算機と接続され、自計算機及び他の計算機のメモリを互いにアクセスすることが可能な計算機であって、
   計算機上で動作中のプロセスから自計算機のＯＳ（オペレーティングシステム）にシステムコールがあった場合、当該システムコールの発行元のプロセッサが自計算機のプロセッサか、他計算機のプロセッサかを判定する判定手段と、
   該判定手段でもって、他計算機上のプロセッサからのシステムコールであると判定した場合、当該システムコールに対する処理を行うプロセッサを、自計算機及び前記他計算機のプロセッサの中から選定する選定手段と、
   選定されたプロセッサに切換え、自計算機のＯＳのシステムコール処理を行う切換手段と
   を備えることを特徴とする計算機。
2. 前記判定手段は、前記システムコールの発行元のプロセッサの識別情報を獲得し、その識別情報に基づいて自計算機のプロセッサか他計算機のプロセッサかを判定することを特徴とする請求項第１項に記載の計算機。
3. 前記選定手段は、自計算機のプロセッサを優先して選定することを特徴とする請求項第１項に記載の計算機。
4. 前記選定手段は、更に、自計算機のプロセッサの負荷が所定以上あると判断した場合、前記他計算機のプロセッサを選定することを特徴とする請求項第３項に記載の計算機。
5. 自計算機が所定の通信媒体を介して他の計算機と接続され、自計算機及び他の計算機のメモリを互いにアクセスすることが可能な計算機の制御方法であって、
   計算機上で動作中のプロセスから自計算機のＯＳ（オペレーティングシステム）のシステムコールがあった場合、当該システムコールの発行元のプロセッサが自計算機のプロセッサか、他計算機のプロセッサかを判定する判定工程と、
   該判定工程でもって、他計算機上のプロセッサからのシステムコールであると判定した場合、当該システムコールに対する処理を行うプロセッサを、自計算機及び前記他計算機のプロセッサの中から選定する選定工程と、
   選定されたプロセッサに切換え、自計算機のＯＳのシステムコール処理を行う切換工程と
   を備えることを特徴とする計算機の制御方法。
6. 前記判定工程は、前記システムコールの発行元のプロセッサの識別情報を獲得し、その識別情報に基づいて自計算機のプロセッサか他計算機のプロセッサかを判定することを特徴とする請求項第５項に記載の計算機の制御方法。
7. 前記選定工程は、自計算機のプロセッサを優先して選定することを特徴とする請求項第５項に記載の計算機の制御方法。
8. 前記選定工程は、更に、自計算機のプロセッサの負荷が所定以上あると判断した場合、前記他計算機のプロセッサを選定することを特徴とする請求項第７項に記載の計算機の制御方法。
9. それぞれに独立したメモリを供えた複数の計算機間を所定の通信媒体で接続し、それぞれのメモリを自計算機管理下のメモリとして利用する計算機システムにおいて、
   プロセスとして生成、起動されたユーザプログラムがシステムコールを発行し、ＯＳ（オペレーティングシステム）を呼び出した際、そのシステムコールを発行したプロセッサが、自計算機上に設置されているローカルプロセッサなのか、それとも通信媒体で結ばれた他の計算機上に設置され管理のみが前記自計算機上に移行しているだけのリモートプロセッサなのかを判断する呼出しプロセッサ判断手段と、
   前記システムコールの指定に従ったＯＳ内部処理を実行すべきプロセッサを選定する実行プロセッサ選定手段と、
   前記実行プロセッサ選定手段により選定されたプロセッサに切り替えを行う実行プロセッサ切り替え手段と
   を備えることを特徴とする計算機システム。
10. 前記呼出しプロセッサ判断手段は、前記システムコールを発行したプロセッサの識別情報を獲得し、その識別情報に基づいてローカルプロ セッサかリモートプロセッサかを判断することを特徴とする請求項第９項に記載の計算機システム。
11. 前記実行プロセッサ選定手段は、ローカルプロセッサを優先して選定することを特徴とする請求項第９項に記載の計算機システム。
12. 前記実行プロセッサ選定手段は、更に、ローカルプロセッサの負荷が所定以上あると判断した場合、前記リモートプロセッサを選定することを特徴とする請求項第１１項に記載の計算機システム。
13. それぞれに独立したメモリを供えた複数の計算機間を所定の通信媒体で接続し、それぞれのメモリを自計算機管理下のメモリとして利用する計算機システムの制御方法において、
    プロセスとして生成、起動されたユーザプログラムがシステムコールを発行し、ＯＳ（オペレーティングシステム）を呼び出した際、そのシステムコールを発行したプロセッサが、自計算機上に設置されているローカルプロセッサなのか、それとも通信媒体で結ばれた他の計算機上に設置され管理のみが前記自計算機上に移行しているだけのリモートプロセッサなのかを判断する呼出しプロセッサ判断工程と、
    前記システムコールの指定に従ったＯＳ内部処理を実行すべきプロセッサを選定する実行プロセッサ選定工程と、
    前記実行プロセッサ選定工程により選定されたプロセッサに切り替えを行う実行プロセッサ切り替え工程と
    を備えることを特徴とする計算機システムの制御方法。
14. 前記呼出しプロセッサ判断工程は、前記システムコールを発行したプロセッサの識別情報を獲得し、その識別情報に基づいてローカルプロセッサかリモートプロセッサかを判断することを特徴とする請求項第１３項に記載の計算機システムの制御方法。
15. 前記実行プロセッサ選定工程は、ローカルプロセッサを優先して選定することを特徴とする請求項第１３項に記載の計算機システムの制御方法。
16. 前記プロセッサ選定工程は、更に、ローカルプロセッサの負荷が所定以上あると判断した場合、前記リモートプロセッサを選定することを特徴とする請求項第１５項に記載の計算機システムの制御方法。

Images