JP4142069B2 - 情報処理装置およびアクセス制御方法 - Google Patents

Description

本発明は情報処理技術に関し、特に複数のタスクの並列処理においてバスを介したデータ伝送を行う情報処理装置およびそのアクセス制御方法に関する。

近年の情報処理技術の著しい進歩に伴い、高速演算を行う情報処理装置がより身近なものになってきた。現在では、プロセッサの演算速度の向上などに伴い、複数のアプリケーションやタスクを並列に処理できる情報処理装置や電子機器が主流となっている。並列処理では、一般的にはタスクを時分割してプロセッサの処理時間を割り当てたり、各アプリケーションに仮想メモリ領域を割り当てたり、といったことが行われる。複数のタスクに対する処理時間やメモリ容量などの割り当ては、オペレーティングシステム（以下、ＯＳと略す）によって行われる。ＯＳはさらに、複数のタスク処理におけるプロセッサとメモリや入出力装置との間のアクセスの排他制御、同期制御なども行う。

一方、プロセッサの高速化や仮想メモリシステムの導入などによって、大量のデータ処理を高速に行うことが可能となるにつれ、データの伝送に用いられるバス帯域の使用効率の問題が顕在化してきた。例えば３次元グラフィックスの動画を表示するゲームなど、リアルタイム性が重要となるアプリケーションを含めた複数のアプリケーションを実行した場合、画像処理が円滑に行われても、他のアプリケーションによって多量のデータがバスを伝送しているために、当該ゲームの画像データ出力処理が阻害されるなどといったことが起こりうる。

これを解決するための一手法として、優先度の高いタスクに対して高い頻度でバスの使用権を与える技術が提案されている（例えば特許文献１参照）。ここではデータ伝送要求を発行する前に、「トークン」と呼ばれる発行許可を得る処理がなされる。トークンはデータ伝送要求の発行元のユニットごとにあらかじめ決められたレートを上限として付与されるため、優先度の低いタスクのデータ伝送のレートを低く設定することにより、他のタスク処理への影響を軽減する。
米国出願公開ＵＳ２００５／０１３８６２１号

一方で、処理の高速化に対する要請は留まることを知らず、より安価かつ実装面積を増やすことなく高速化を実現できる技術が望まれている。しかしながら、例えば上記のようにバス帯域を効率的に使用する技術においても、トークンを付与するという処理によってレイテンシが発生し、処理時間の遅延に繋がる可能性があることを本発明者は認識した。

本発明はこのような課題に鑑みてなされたものであり、その目的は複数のタスク処理におけるバスの使用を、適応的かつ効率的に行うことのできる技術を提供することにある。

本発明のある態様は情報処理装置に関する。この情報処理装置は、リソースへのアクセス要求の発行許可を求める複数のリクエスタユニットと、アクセス要求が所定のレートで発行されるように制御したうえでリクエスタユニットに発行許可を出す発行レート制御部と、発行許可を得たアクセス要求を受け付け蓄積し、順次アクセスを実現するアクセス処理部と、を備え、アクセス処理部におけるアクセス要求の蓄積量が所定の第１のしきい値以下であるとき、複数のリクエスタユニットの少なくとも一部を、発行レート制御部による制御と独立にアクセス要求を発行する優先リクエスタユニットとすることを特徴とする。

ここで「リクエスタユニット」および「リソース」はプロセッサ、メモリ、入出力装置など情報処理装置に搭載された一般的なハードウェアモジュールでもよいし、それらを物理的、または仮想的に区分けしたそれぞれ、およびそれらの組み合わせでもよい。またプロセス、タスク、スレッドなど実行される処理単位としてもよく、アクセスの発行元、またはアクセス先として機能する何らかの処理単位に対応すればよい。

本発明の別の態様はアクセス制御方法に関する。このアクセス制御方法は、リクエスタユニットがリソースへのアクセス要求を所定のレートで発行するステップと、アクセス要求を蓄積し、順次アクセスを実現するステップと、を含み、発行するステップは、アクセス要求の蓄積量が所定のしきい値以下であるとき、当該所定のレートで定まるタイミング以外のタイミングでも、アクセス要求を発行することを特徴とする。

本発明の別の態様はアクセス制御方法に関する。このアクセス制御方法は、トークンを取得したリクエスタユニットがリソースへのアクセス要求を発行するステップと、アクセス要求を蓄積し、順次アクセスを実現するステップと、を含み、アクセス要求の蓄積量が所定のしきい値以下であるときは、トークンを取得していないリクエスタユニットがリソースへのアクセス要求を発行するステップをさらに含むことを特徴とする。

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、コンピュータプログラムなどの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、複数のタスクの並列処理においてユニット間のアクセスを効率的に行うことができる。

（実施の形態１）
図１は本実施の形態における情報処理装置の構成を示している。情報処理装置１００はロードされたアプリケーションやＯＳを実行するプロセッサユニット１０、実行中のプログラムや実行に必要なデータを記憶するメモリ１８、メモリ１８に対するアクセスを制御するメモリコントローラ１６、ユーザからの入力受け付けやデータ出力などを行う第１入出力装置２２ａおよび第２入出力装置２２ｂ、第１入出力装置２２ａおよび第２入出力装置２２ｂに対するアクセスをそれぞれ制御する第１入出力装置コントローラ２０ａおよび第２入出力装置コントローラ２０ｂ、メモリ１８や第１入出力装置２２ａ、第２入出力装置２２ｂへのアクセス要求に対するトークンを管理するトークンマネージャ１２を含む。トークンについては後に詳述する。

プロセッサユニット１０、メモリ１８、第１入出力装置２２ａ、第２入出力装置２２ｂの間のデータ伝送は、バス１４を介して行われる。実際には各ユニット間のデータ伝送路、またはデータの往路、復路としてそれぞれ専用のバスを設けてよいが、ここでは簡単のため一の線で示している。各ユニット間のデータ伝送で使用できるバス１４のバス帯域は、あらかじめシミュレーションなどによって個々に設定しておく。その値は、ユニットの接続状況などに応じて複数の設定から適宜選択できるようにしてもよい。また本実施の形態における各ユニットとバス１４との接続関係は図１に示したものに限定されず、各ユニットがここで述べる機能を実現できればよい。

第１入出力装置２２ａ、第２入出力装置２２ｂはキーボード、マウスなどの入力装置、ハードディスクドライブ、ＤＶＤ（Digital Versatile Disk）やＣＤ（Compact Disk）などの記録媒体の読取装置、表示装置、プリンタ、グラフィックプロセッサなどの各種プロセッサユニット、ブリッジチップ、ネットワーク用のチップなどのいずれか、またはそれらの組み合わせでよい。したがって入出力装置の数は限定されないが、図１および以後の説明では簡単のためそれらの入出力装置を第１入出力装置２２ａ、第２入出力装置２２ｂとして代表させる。同様に、各入出力装置に対応する入出力装置コントローラを第１入出力装置コントローラ２０ａ、第２入出力装置コントローラ２０ｂで代表させる。

本実施の形態におけるプロセッサユニット１０は、複数のタスクを並列に処理する。各タスクは時分割され、それぞれに対しプロセッサユニット１０における処理時間を割り当てることにより順次処理される。プロセッサユニット１０は複数のプロセッサ（図示せず）からなる構成でもよい。このときは例えば、複数のプロセッサのうちの１つを制御用プロセッサと位置づけ、他のプロセッサによるタスク処理のスケジューリングや切り替えを制御する。

第１入出力装置コントローラ２０ａは、プロセッサユニット１０や別の入出力装置コントローラ、すなわち第２入出力装置コントローラ２０ｂからのアクセス要求を受け付け、対応する第１入出力装置２２ａと、プロセッサユニット１０や別の入出力装置、すなわち第２入出力装置２２ｂとの間におけるデータの送受を実施する。さらに第１入出力装置コントローラ２０ａは、対応する第１入出力装置２２ａからメモリ１８や他の入出力装置、すなわち第２入出力装置２２ｂへのアクセス要求も行う。アクセス確立によるデータの送受は、第１入出力装置２２ａに接続されたバス２６ａを介して行われる。

第２入出力装置コントローラ２０ｂは、プロセッサユニット１０や別の入出力装置コントローラ、すなわち第１入出力装置コントローラ２０ａからのアクセス要求を受け付け、対応する第２入出力装置２２ｂと、プロセッサユニット１０や別の入出力装置、すなわち第１入出力装置２２ａとの間におけるデータの送受を実施する。さらに第２入出力装置コントローラ２０ｂは、対応する第２入出力装置２２ｂからメモリ１８や他の入出力装置、すなわち第１入出力装置２２ａへのアクセス要求も行う。アクセス確立によるデータの送受は、第２入出力装置２２ｂに接続されたバス２６ｂを介して行われる。

メモリ１８はＤＲＡＭ（Dynamic Random Access Memory）やＳＲＡＭ（Static Random Access Memory）など一般的に用いられるメモリで構成してよい。メモリコントローラ１６は、プロセッサユニット１０や第１入出力装置コントローラ２０ａ、第２入出力装置コントローラ２０ｂからメモリ１８へのアクセス要求を受け付け、プロセッサユニット１０や第１入出力装置２２ａ、第２入出力装置２２ｂとメモリ１８との間におけるデータの送受を実施する。データの送受は、メモリ１８に接続されたバス２４を介して行われる。

トークンマネージャ１２はプロセッサユニット１０からメモリ１８または第１入出力装置２２ａ、第２入出力装置２２ｂへのアクセス要求、第１入出力装置コントローラ２０ａからメモリ１８または第２入出力装置２２ｂへのアクセス要求、および第２入出力装置コントローラ２０ｂからメモリ１８または第１入出力装置２２ａへのアクセス要求の発行を許可するか否かを決定する。ここでアクセス要求は所定の書き込み／読み出しデータサイズごとに行う。すなわちアクセス先のメモリ１８、第１入出力装置２２ａ、または第２入出力装置２２ｂから読み出されるデータ、またはそれらへ書き込まれるデータは、同一サイズのパケットとしてそれぞれに接続されたバス、すなわちバス２４、バス２６ａ、バス２６ｂに送られる。

１度のアクセス要求で伝送されるデータのサイズが同一であれば、アクセス要求を許可する最大レートを調整することによって、アクセス要求発行元が使用するバス帯域を制限することができる。そして各アクセス要求発行元が使用できる最大バス帯域の合計が、データが伝送するバスのバス帯域を越えないように、最大レートをそれぞれ設定すれば、全ての要求発行元が望ましい割合でバス帯域をシェアすることが可能となる。

そこでトークンマネージャ１２にはあらかじめ、アクセス要求の発行元ごとに、それぞれのバスを介したアクセス要求を許可する最大レートを設定しておく。バス帯域の制限を、最大レートによって生成されるトークンとして実体化し、トークンを取得した発行元のみがアクセス要求を発行できるようにする。実装されたバス帯域がアクセス先ごとに異なる場合は、バス帯域に対応したトークンの生成レートを、アクセス先ごとに設定する。

これにより、例えば優先度の低いタスクによってバス帯域が占領され、リアルタイム性を要求されるタスクの、メモリ１８や第１入出力装置２２ａ、第２入出力装置２２ｂへのアクセスが阻害される、といったことが発生しにくくなる。

ここでトークンマネージャ１２の処理についてさらに詳しく説明する。図２はプロセッサユニット１０または第１入出力装置コントローラ２０ａ、第２入出力装置コントローラ２０ｂによるメモリ１８へのアクセス要求に係るトークンマネージャ１２およびメモリコントローラ１６における処理手順を説明する図である。同図ではメモリ１８へのアクセス要求を説明するため、メモリコントローラ１６のみが示されているが、第１入出力装置２２ａ、または第２入出力装置２２ｂへのアクセス要求であれば、メモリコントローラ１６に代わり第１入出力装置コントローラ２０ａ、または第２入出力装置コントローラ２０ｂがそれぞれ同様の処理を行う。以後の説明においても理解を容易にするためメモリコントローラ１６を例に説明するが、第１入出力装置コントローラ２０ａまたは第２入出力装置コントローラ２０ｂに置き換えることも可能である。したがって以後の説明で制御対象となる使用バス帯域は、メモリ１８に接続されたバス２４のバス帯域であるが、これも第１入出力装置２２ａに接続されたバス２６ａ、または第２入出力装置２２ｂに接続されたバス２６ｂのバス帯域に適宜置き換えることができる。

図２において、様々な処理を行う機能ブロックとして記載される各要素は、ハードウェア的には、ＣＰＵ、メモリ、その他のＬＳＩで構成することができ、ソフトウェア的には、要素間でのデータの送受を実現するプログラムなどによって実現される。したがって、これらの機能ブロックがハードウェアのみ、ソフトウェアのみ、またはそれらの組合せによっていろいろな形で実現できることは当業者には理解されるところであり、いずれかに限定されるものではない。

例えば第１リクエスタ３０ａから第ｎリクエスタ３０ｎのｎ個のリクエスタは、プロセッサユニット１０に含まれるプロセッサや第１入出力装置コントローラ２０ａ、第２入出力装置コントローラ２０ｂに対応してもよいし、情報処理装置１００において処理されるプロセスやタスクごとに割り当てられた、プロセッサの仮想的な区画などに対応してもよい。いずれにしろ第１リクエスタ３０ａ〜第ｎリクエスタ３０ｎは、メモリ１８へのアクセス要求を発行する発行元となりうる要素の単位とする。

トークンマネージャ１２は、トークンを所定のレートで生成するトークン生成部３６および、アクセス要求の発行許可を求めた第１リクエスタ３０ａ〜第ｎリクエスタ３０ｎのそれぞれに対し、生成したトークンを付与するトークン付与部３４を含む。トークン生成部３６におけるトークンの生成レートはリクエスタごとに異なる。あるいは、第１リクエスタ３０ａ〜第ｎリクエスタ３０ｎをその重要性や処理態様などに鑑みグルーピングし、グループごとに生成レートを異ならせてもよい。例えばグラフィックス処理を行う第１リクエスタ３０ａおよび第２リクエスタ３０ｂ、文書処理を行う第３リクエスタ３０ｃおよび第４リクエスタ３０ｄなどによってアクセス先に偏りがあったりアクセス頻度に特徴があったりする場合があるため、グルーピングによって適正な生成レートを設定することにより、リソースをより効率的に使用することが可能となる。

前者の場合、第１リクエスタ３０ａ〜第ｎリクエスタ３０ｎのそれぞれに対し、専用のトークンが、それぞれのレートで生成される。後者の場合、グループごとに専用のトークンがそれぞれのレートで生成され、同じグループに所属するリクエスタ、例えば第１リクエスタ３０ａおよび第２リクエスタ３０ｂがそのトークンを分け合う。なお以後の説明では、第１リクエスタ３０ａ〜第ｎリクエスタ３０ｎをリクエスタのグループと置き換えてもよい。各リクエスタとトークンの生成レートとの対応はトークンマネージャ１２の図示しないレジスタにあらかじめ設定しておく。生成レートは各リクエスタの特徴や重要性などに鑑み、実験やシミュレーションにより決定できる。

トークン生成部３６は生成したトークンを、次の生成周期が到来するまで保持しておく。そしてその間に第１リクエスタ３０ａ〜第ｎリクエスタ３０ｎのいずれかから要求があった場合は、トークン付与部３４から要求元のリクエスタへトークンが付与される。要求がなかった場合は、次の生成周期が到来した際、保持していたトークンを破棄し、新たなトークンを生成する。このとき、場合によってはトークンが不足している別のリクエスタに余分となったトークンを譲渡してもよい。

メモリコントローラ１６は、トークンを付与されたリクエスタがメモリ１８へのアクセス要求を発行した際、当該要求を蓄積していくコマンドキュー３２を含む。メモリコントローラ１６は、コマンドキュー３２に蓄積された要求を順次処理することにより、メモリ１８と要求発行元のリクエスタとの間のアクセス処理、すなわちバス１４および２４を介したデータ伝送を実施する。

次に図２に示した例に基づき、アクセス処理を実現する手順を説明する。まず第１リクエスタ３０ａ〜第ｎリクエスタ３０ｎのうち、第４リクエスタ３０ｄにおいてメモリ１８へのアクセスの必要が生じたとする。このときまず第４リクエスタ３０ｄは、トークンマネージャ１２に対しアクセス要求を発行したい旨の通知を行い、トークンを請求する（Ｓ４０）。この通知には第１リクエスタ３０ａ〜第ｎリクエスタ３０ｎを識別する情報を含める。

トークン付与部３４はリクエスタの識別情報に基づき、第４リクエスタ３０ｄに付与できるトークンの有無を確認する。そしてトークンがあれば、それを要求元の第４リクエスタ３０ｄに付与する（Ｓ４２）。ここで、第４リクエスタ３０ｄに対するトークン、あるいは第４リクエスタ３０ｄの属するグループに対するトークンが、トークン生成の１周期内ですでに別の要求により使われてしまっている場合は、トークン生成部３６において次にトークンが生成されるまで付与の処理を待機する。

第４リクエスタ３０ｄはトークンを取得した場合に限り、メモリコントローラ１６に対しメモリ１８へのアクセス要求を発行することができる（Ｓ４４）。アクセス要求には読み出し又は書き込みのコマンドと、それに必要なアドレス情報などを含める。メモリコントローラ１６は、当該アクセス要求を受け付け、コマンドキュー３２に蓄積する。そして先に蓄積したアクセス要求から順次アクセス処理を実施していく。

以上の処理により、例えば第４リクエスタ３０ｄが連続してメモリ１８に対しアクセスをしようとしても、実際にアクセス要求を発行できるのは所定のレート以下となるため、他のリクエスタが実行中の優先されるべき処理に支障をきたすといった事態の発生を抑制することができる。

一方で、トークンを導入することにより新たなオーバヘッドが発生しうる。例えば上記の手順によって、トークンマネージャ１２が第４リクエスタ３０ｄからのトークンの要求を受け付け、トークンを付与するまでには、使用されていないトークンが存在する場合であっても、トークンマネージャ１２内の各処理によりレイテンシが発生する。さらに第４リクエスタ３０ｄ内部でも、トークンを要求するための処理によりレイテンシが発生する。

さらに、複数のリクエスタ、または異なるグループに属するリクエスタが、それぞれのトークンを取得して、同じメモリ１８へのアクセス要求をメモリコントローラ１６にほぼ同時に発行するような場合、メモリコントローラ１６ではそれらの要求の受け付け処理を順次行うためのレイテンシが生じる。

そこで本実施の形態ではコマンドキュー３２に蓄積されたアクセス要求の数に応じてトークンを生成するレートを変化させる。このため、蓄積量に関する情報を、メモリコントローラ１６からトークンマネージャ１２に送信する（Ｓ４６）。具体的には蓄積量が小さい段階においては、実装されたバス帯域を超過するレート、例えば２００％以上のレートでトークンを生成し、超過分のトークンはどのリクエスタでも取得できるようにする。これにより、トークン付与やアクセス要求の受け付け処理によるアクセス処理のオーバヘッドを抑制することができる。

図３はコマンドキュー３２におけるアクセス要求の蓄積量に設定するレベルを説明する図である。同図のコマンドキュー３２においてアクセス要求の蓄積量ｑは、最下位がｑ＝０、すなわちアクセス要求が蓄積されていない状態、最上位がコマンドキュー３２に蓄積できる最大量ｑ＝Ｑｍａｘが蓄積されている状態とする。そして図に示すようにｑ＝Ｑ１、ｑ＝Ｑ２（０＜Ｑ１＜Ｑ２＜Ｑｍａｘ）という２つのしきい値を設定する。以後の説明では蓄積量ｑが０≦ｑ≦Ｑ１なる範囲を「レベル０」、Ｑ１＜ｑ≦Ｑ２なる範囲を「レベル１」、Ｑ２＜ｑ≦Ｑｍａｘなる範囲を「レベル２」と呼ぶ。

まず、第１リクエスタ３０ａ、第２リクエスタ３０ｂ、・・・、第ｎリクエスタ３０ｎに対するトークンの生成レート（単位時間当たりに生成するトークンの数）をそれぞれＲ１、Ｒ２、・・・、Ｒｎ（トークン／秒）としたとき、第１リクエスタ３０ａ〜第ｎリクエスタ３０ｎが最大限のアクセスを行ったときに使用されるバス帯域が実装されたバス帯域Ｂ（バイト／秒）と等しくなるように生成レートを設定する。すなわち、１度のアクセス処理で伝送されるデータサイズをＤ（バイト／トークン）とすると、
（Ｒ１＋Ｒ２＋・・・＋Ｒｎ）×Ｄ＝Ｂ （式１）
となるように、生成レートＲ１、Ｒ２、・・・、Ｒｎを設定する。

次にレベル０では上述のとおり、実装されたバス帯域を超過したレートでトークンを生成する。すなわち、全トークンの生成レートの合計をＲ（トークン／秒）とすると、
Ｒ×Ｄ＞Ｂ （式２）
となるようなレートＲでトークンを生成する。例えばバス帯域の２００％のレートとすると、Ｒ＝２Ｂ／Ｄと設定される。ここで超過分の生成レートＲｏ（トークン／秒）、すなわち
Ｒｏ＝Ｒー（Ｒ１＋Ｒ２＋・・・＋Ｒｎ） （式３）
で生成されるトークンは、未割り当てトークンとし、トークンを要求したリクエスタのいずれに付与してもよいこととする。

これにより、要求のあったトークンが生成されるまでの待機時間が解消する場合が増え、トークン要求から付与までに要する時間が全体的に少なくなる。したがって、コマンドキュー３２におけるアクセス要求の蓄積量が少なく、トークン付与処理やアクセス要求受け付け処理などに起因して、アクセス処理にオーバヘッドが発生する可能性が高い状況において、トークン付与処理を迅速に行うことができる。また、一時的にアクセス要求の発行レートが増えるため、蓄積量が少ない状況自体を早急に脱することができる。

レベル１では未割り当てトークンの生成を行わず、第１リクエスタ３０ａ〜第ｎリクエスタ３０ｎに対するトークンを式１に示すようなレートでそれぞれ生成する。これにより、第１リクエスタ３０ａ〜第ｎリクエスタ３０ｎが適正な割合でバス帯域を確保することができ、バス帯域の不足によってアクセス処理が著しく遅延することがなくなる。また、レベル０と比較してコマンドキュー３２におけるアクセス要求の蓄積速度が遅くなるため、蓄積量ｑがｑ＝Ｑｍａｘへ到達してメモリコントローラ１６がアクセス要求を受け付けられなくなる可能性を抑制することができる。メモリコントローラ１６がアクセス要求を受け付けられなくなると、第１リクエスタ３０ａ〜第ｎリクエスタ３０ｎがアクセス要求を再発行するためにさらなる時間を要し、アクセスの実施が大きく遅れる可能性がある。

レベル２では全トークンの生成を停止する。これにより、その段階でトークンを取得済みのリクエスタ以外はアクセス要求を発行できなくなる。そのためリクエスタは、一度発行したアクセス要求を受け付けられずに、アクセス要求を再発行しなければならない状況が発生しにくくなり、上述のようなレイテンシの発生を抑制することができる。

図４は図３に示したコマンドキュー３２の構造に基づき、トークンマネージャ１２のトークン生成部３６が実行するトークン生成スキームの例を示している。まず、コマンドキュー３２の蓄積量がレベル０、レベル１、レベル２の境界のいずれかを越えた際、図２のＳ４６に示したように、メモリコントローラ１６からトークンマネージャ１２へその旨の通知信号が送信される。トークンマネージャ１２はその通知信号に基づき、内部に設けられたレジスタ（図示せず）に、現在のコマンドキュー蓄積量のレベルを書き込んでおく。

そしてトークン生成部３６は、トークン生成周期ごとに当該レジスタを確認する。レジスタの値がレベル０を示していたら（Ｓ１０のＹ）、未割り当てトークンを含み、実装されたバス帯域の２００％に対応するレートでトークンを生成する（Ｓ１２）。すなわち、第１リクエスタ３０ａ〜第ｎリクエスタ３０ｎに対するトークンの合計を実装されたバス帯域の１００％分、さらに未割り当てトークンをバス帯域の１００％分生成する。なお、この割合は例示であり、実装されたバス帯域と等価なレートより多いレートで全トークンが生成されればよい。全トークンの生成レートや、全トークンのうちの未割り当てトークンの占める割合は、コマンドキュー３２の容量やアクセス要求の蓄積速度などによって最適な値を、実験やシミュレーションなどにより適宜求める。

レジスタの値がレベル１を示していたら（Ｓ１４のＹ）、未割り当てトークンの生成を停止し、第１リクエスタ３０ａ〜第ｎリクエスタ３０ｎのそれぞれに対するトークンのみを、実装されたバス帯域の１００％と対応するレートで生成する（Ｓ１６）。

レジスタの値がレベル０、レベル１のいずれでもない場合（Ｓ１０のＮ、Ｓ１４のＮ）、すなわちレジスタの値がレベル２を示している場合は、全トークンの生成を停止する（Ｓ１８）。

なお、図４の説明では本実施の形態をトークン生成部３６の動作で実現した場合を示したが、同様の制御をトークン付与部３４の動作で実現してもよい。すなわち、トークン生成部３６では、未割り当てトークンを含むトークンを、実装されたバス帯域の２００％に対応するレートで常時生成する。そして、リクエスタからトークンの要求を受け付けた際、トークン付与部３４はレジスタの値を確認する。レベル０においては、要求元のリクエスタに対する専用トークンが存在しない場合、未割り当てトークンを当該リクエスタに付与する。レベル１の場合は、未割り当てトークンは付与しない。レベル２ではトークンの付与を停止する。

以上述べた本実施の形態によれば、メモリコントローラ１６や、第１入出力装置コントローラ２０ａ、あるいは第２入出力装置コントローラ２０ｂへのアクセス要求の、コマンドキューにおける蓄積量にしきい値を設ける。そして蓄積量が０からあるしきい値までの範囲であるとき、すなわち蓄積量が少ないときは、最大使用バス帯域が実装されたバス帯域を越えるようなレートでトークンを生成する。これにより、トークンの付与に要する時間が削減されるとともに、コマンドキュー３２におけるアクセス要求の蓄積速度が上昇し、メモリコントローラ１６や、第１入出力装置コントローラ２０ａ、あるいは第２入出力装置コントローラ２０ｂにおいてアクセス要求の受け付けが重なった場合に発生するレイテンシを吸収できる。結果として、メモリ１８や第１入出力装置２２ａ、あるいは第２入出力装置２２ｂに対してアクセスを行うためのトークン付与、アクセス要求受け付けといった処理に起因して発生するオーバヘッドを抑制できる。

また前述したしきい値を超え蓄積量が十分ある場合は、実装されたバス帯域と等価なレートでトークンを生成し、各リクエスタに割り当てる。これによりトークン付与処理やアクセス要求の受け付けによりレイテンシが発生しても、その間にメモリコントローラ１６や第１入出力装置コントローラ２０ａ、あるいは第２入出力装置コントローラ２０ｂで処理されるべきアクセス要求はコマンドキュー３２に蓄積されている。したがってオーバヘッドを増加させることなく、適正なバス帯域の割り当てを行うことができる。

また本実施の形態はＯＳにおいて新たな設定を加えることによって実現できるため、新たな回路の導入やバス帯域の増強といったハードウェアによるアプローチと異なり、安価かつ実装面積に影響を与えることなく汎用的に実施が可能である。

（実施の形態２）
実施の形態１では、コマンドキュー３２におけるアクセス要求の蓄積量によって、トークンの生成レートまたはトークンの付与レートをバス帯域を超過した値から段階的に減少させていくことにより、アクセス処理におけるオーバヘッドの発生を抑制した。本実施の形態では、コマンドキュー３２におけるアクセス要求の蓄積量が少ない状況においてトークンの付与処理を省略できる場合を設け、さらにオーバヘッドの発生を抑制する。本実施の形態は、図１で示した情報処理装置１００と同様の構成、および、図２において説明したアクセス処理手順と同様の手順で実現することができる。以後、主に実施の形態１と異なる点を説明する。

トークンは第１リクエスタ３０ａ〜第ｎリクエスタ３０ｎの特徴や優先度などに鑑みバス帯域の使用レートを調停するために導入される。したがって、各リクエスタによるアクセス要求が重なり、バス帯域が不足する傾向にあるときにより効果を発揮する。一方、コマンドキュー３２におけるアクセス要求の蓄積量が少ない場合、トークンによってバス帯域の使用を厳密に調停しなくても、各アクセス処理が円滑に行われる可能性が高いことに本発明者は想到した。

そこで実施の形態１で示したトークン生成レートのためのレベル分けとは別のレベル分け、すなわちトークンの付与処理を省略するためのレベル分けを導入する。さらに各リクエスタに優先度を設定し、新たに導入したレベルによってトークンの付与処理を省略してよいリクエスタの数を変化させる。

図５は本実施の形態のコマンドキュー３２におけるアクセス要求の蓄積量に設定するレベルを説明する図である。アクセス要求の蓄積量ｑにＱ１、Ｑ２なるしきい値を設ける点は実施の形態１と同様である。これらのしきい値に対するトークンマネージャ１２の動作の変化も実施の形態１と同様に行う。ただし、以後の説明では便宜上、蓄積量ｑが０≦ｑ≦Ｑ１なる範囲を「生成レベル０」、Ｑ１＜ｑ≦Ｑ２なる範囲を「生成レベル１」、Ｑ２＜ｑ≦Ｑｍａｘなる範囲を「生成レベル２」と呼ぶ。

一方、本実施の形態では、アクセス要求の蓄積量ｑに、さらにＳ１、Ｓ２（０＜Ｓ１＜Ｓ２＜Ｑ１）なるしきい値を設ける。以後の説明では蓄積量ｑが０≦ｑ≦Ｓ１なる範囲を「スキップレベル０」、Ｓ１＜ｑ≦Ｓ２なる範囲を「スキップレベル１」、Ｓ２＜ｑ≦Ｑｍａｘなる範囲を「スキップレベル２」と呼ぶ。図から明らかなように、本実施の形態ではアクセス要求の蓄積量は、スキップレベルと生成レベルの２種類のレベルで表現される。

図５では、しきい値Ｓ１およびＳ２、すなわちスキップレベルの境界のいずれも、生成レベル０に含まれている。このときはスキップレベルが変化しても、トークン生成部３６では実施の形態１のレベル０の場合と同様、式２で表されるバス帯域を超過した所定のレートＲで未割り当てトークンと各リクエスタに対するトークンが生成されているものとする。したがって以後の説明ではスキップレベルの変化に対する情報処理装置１００の動作の変化のみを説明する。ただし、スキップレベルの境界は生成レベル０内に限定されず、スキップレベルによる動作の変化と、生成レベルによる動作の変化を適宜組み合わせてよい。

図６は第１リクエスタ３０ａ〜第ｎリクエスタ３０ｎのそれぞれに設定される優先度と、スキップレベルとに応じた、トークン付与処理省略のルールを示すテーブルである。以後、トークン付与処理を省略できるリクエスタにはトークンに変わり、フリーパス（以後、ＦＰと呼ぶ）を付与する、として説明する。ＦＰ付与ルールテーブル５０は、リクエスタに付与される優先度を示した優先度欄５２、およびスキップレベルを示したスキップレベル欄５４を含む。これを参照することによりそれぞれのスキップレベルにおいて各リクエスタにＦＰを付与するか省略を無効とするかを一意に決定する。ＦＰ付与ルールテーブル５０はトークンマネージャ１２の図示しないレジスタやメモリ１８などに記憶しておく。

同図では優先度欄５２に２〜０までの優先度が設定されている。ここでは優先度２を高優先度、優先度０を低優先度とする。優先度が高いリクエスタはスキップレベル０およびスキップレベル１の、より広い範囲で、ＦＰを付与される。ＦＰが付与されている間は、トークンの取得を省略してメモリコントローラ１６や第１入出力装置コントローラ２０ａ、あるいは第２入出力装置コントローラ２０ｂへアクセス要求を発行できる。一方、優先度が低いリクエスタは、いかなる場合でもＦＰは付与されず、トークンを取得した場合にのみアクセス要求を発行する。優先度が中間の場合は、優先度が高い場合より狭い範囲、例えばスキップレベル０のときのみ、ＦＰを付与される。

ここで優先度は第１リクエスタ３０ａ〜第ｎリクエスタ３０ｎのそれぞれに対し設定してもよいし、トークンの発生レートをリクエスタのグループごとに設定している場合などは、そのグループごとに設定してもよい。優先度は第１リクエスタ３０ａ〜第ｎリクエスタ３０ｎやそのグループの重要度や処理の特徴などに鑑み実験やシミュレーションにより決定し、トークンマネージャ１２内部の図示しないレジスタに設定する。または第１リクエスタ３０ａ〜第ｎリクエスタ３０ｎ内のレジスタ、あるいはプログラム内で設定してもよい。

「ＦＰの付与」は実際には次のように行われる。メモリコントローラ１６、第１入出力装置コントローラ２０ａ、あるいは第２入出力装置コントローラ２０ｂは、コマンドキュー３２の蓄積量がスキップレベル０、スキップレベル１、スキップレベル２の境界のいずれかを越えた際、実施の形態１の図２におけるＳ４６に示したように、トークンマネージャ１２へその旨の通知信号を送信する。トークンマネージャ１２はその通知信号に基づき、内部に設けられたレジスタ（図示せず）に、現在のスキップレベルを書き込む。

さらにトークンマネージャ１２はスキップレベルに基づきＦＰ付与ルールテーブル５０を参照して各リクエスタにＦＰを付与するか、無効とするかを決定する。ＦＰを付与する場合は、メモリ１８に各リクエスタに対応して設けられたフラグ、または各リクエスタが有するレジスタに用意されたフラグなどを「１」などとセットする。ＦＰを無効とする場合は当該フラグを「０」などとリセットする。あるいは第１リクエスタ３０ａ〜第ｎリクエスタ３０ｎがそれぞれ、アクセス要求を行う際などに現在のスキップレベルとＦＰ付与ルールテーブル５０を確認して、自らのフラグを書き換えてもよい。

図７は本実施の形態において第１リクエスタ３０ａ〜第ｎリクエスタ３０ｎが行うアクセス要求発行手順を示している。まずメモリ１８、第１入出力装置コントローラ２０ａ、あるいは第２入出力装置コントローラ２０ｂにアクセスを行う必要が生じた場合、第１リクエスタ３０ａ〜第ｎリクエスタ３０ｎは自分がＦＰを取得しているかどうかを確認する（Ｓ３０）。上述のとおりこの処理は実際には、メモリ１８などに用意されたフラグが「１」とセットされているか「０」とセットされているかを確認する。ＦＰを取得していたら（Ｓ３０のＹ）、当該リクエスタはメモリコントローラ１６、第１入出力装置コントローラ２０ａ、あるいは第２入出力装置コントローラ２０ｂに直接アクセス要求を発行する（Ｓ３６）。

ＦＰを取得していなかったら（Ｓ３０のＮ）、実施の形態１で説明したのと同様、トークンマネージャ１２にトークンを要求する（Ｓ３２）。そしてトークンマネージャ１２がトークン生成、付与に係る必要な処理を行うことによりトークンが取得できたら（Ｓ３４）、要求元のリクエスタはメモリコントローラ１６、第１入出力装置コントローラ２０ａ、あるいは第２入出力装置コントローラ２０ｂにアクセス要求を発行する（Ｓ３６）。

図８は本実施の形態においてトークンマネージャ１２が、第１リクエスタ３０ａ〜第ｎリクエスタ３０ｎに順次ＦＰを付与していくスキームの例を示している。メモリコントローラ１６、第１入出力装置コントローラ２０ａ、あるいは第２入出力装置コントローラ２０ｂからのスキップレベルの変更を通知する信号を受けると、トークンマネージャ１２はそのスキップレベルを当該通知信号または一旦その情報を書き込んだレジスタの値により確認する。スキップレベル０であったら（Ｓ４０のＹ）、次は付与対象となるリクエスタの優先度を確認する。

優先度１（Ｓ４２のＹ）または優先度２であったら（Ｓ４２のＮおよびＳ４６のＹ）、図６のＦＰ付与ルールテーブル５０に基づき、ＦＰを付与する（Ｓ５０）。ＦＰの付与は上述のとおり、対象となるリクエスタのフラグをセットすることによって行われる。優先度０であったら（Ｓ４６のＮ）、ＦＰ付与ルールテーブル５０に基づき、ＦＰを無効にし、フラグをリセットする（Ｓ４８）。

同様に、スキップレベル１で（Ｓ４０のＮおよびＳ４４のＹ）、優先度２であったら（Ｓ４６のＹ）、ＦＰを付与する（Ｓ５０）。それ以外の場合（Ｓ４４のＹおよびＳ４６のＮ、Ｓ４４のＮ）はＦＰを無効とする（Ｓ４８）。以上の処理を、全てのリクエスタ、第１リクエスタ３０ａ〜第ｎリクエスタ３０ｎに対して行い（Ｓ５２のＹ）、ＦＰの付与、無効を更新する。

以上述べた本実施の形態によれば、メモリコントローラ１６や第１入出力装置コントローラ２０ａ、あるいは第２入出力装置コントローラ２０ｂのコマンドキュー３２におけるアクセス要求の蓄積量に２系統のしきい値を設ける。第一の系統は実施の形態１と同様、トークンの生成レートを変化させるしきい値であり、第二の系統はトークンの取得処理を省略するためのしきい値である。第一の系統においてトークンの生成レートがバス帯域を越える態様を設けることにより、実施の形態１で説明したのと同様、トークン付与処理におけるレイテンシを削減できる。さらにアクセス要求が重なった際のメモリコントローラ１６や第１入出力装置コントローラ２０ａ、あるいは第２入出力装置コントローラ２０ｂの受け付け処理におけるレイテンシを、コマンドキュー３２におけるアクセス要求の蓄積量を十分に保つことにより吸収する。結果として、アクセス処理が実施されるまでのオーバーヘッドを軽減することができる。

さらに第２の系統において特定のリクエスタに対しトークンを取得せずにアクセス要求の発行を許す態様を設けることにより、トークン付与に要する処理時間やリソースを節約することができる。

トークンの取得を省略するのは、バス帯域が比較的空いている状況下であるため、トークンによる使用バス帯域の調停機能が一部省略されることによる影響は発生しにくい。さらにバス帯域が空いている状況においても、優先度の低いリクエスタにはトークンの取得が課せられるため、そのようなリクエスタのアクセス要求が集中して他のリクエスタのアクセス処理が滞る状況は発生しにくい。そのうえでトークン付与処理を省略するため、トークン導入の効果を確保しながらアクセスの実施までのオーバーヘッドをさらに軽減することができる。またバス帯域を有効に利用することができる。また実施の形態１と同様、導入コストや実装面積の点で有利に導入することができる。

以上、本発明を実施の形態をもとに説明した。上記実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。

例えば実施の形態２では、ＦＰが付与されているか無効かをリクエスタ自信が確認し、その結果によってトークンマネージャ１２へトークンを要求するか、トークンの要求をせずにメモリコントローラ１６などへアクセス要求を発行するかを決定した。一方、全てのリクエスタ、第１リクエスタ３０ａ〜第ｎリクエスタ３０ｎはいったんトークンマネージャ１２へトークンを要求し、トークンマネージャ１２において、ＦＰが付与されているリクエスタを識別するようにしてもよい。このときＦＰが付与されているリクエスタには、常時用意されている特殊なトークンを付与してすぐにアクセス要求の発行許可を出す。これにより、第１リクエスタ３０ａ〜第ｎリクエスタ３０ｎの動作についてはＦＰの導入のない場合から変更することなく、実施の形態２と同様の効果を達成することができる。

また、実施の形態２では生成レベルとスキップレベルという二つのレベル分けにより、トークンの生成レートおよびトークン付与処理を省略するリクエスタを変化させたが、スキップレベルのみを導入してもよい。この場合も、トークン付与に要する処理時間やリソースを節約することができ、オーバーヘッドの軽減、バス帯域の有効利用といった効果を安価に得ることができる。

実施の形態１における情報処理装置の構成を示す図である。 実施の形態１のメモリへのアクセス要求に係るトークンマネージャおよびメモリコントローラにおける処理手順を説明するための図である。 実施の形態１において、コマンドキューにおけるアクセス要求の蓄積量に設定するレベルを説明する図である。 実施の形態１におけるトークン生成部が実行するトークン生成スキームの例を示す図である。 実施の形態２において、コマンドキューにおけるアクセス要求の蓄積量に設定するレベルを説明する図である。 実施の形態２において、リクエスタの優先度とスキップレベルとに応じた、トークン付与処理省略のルールを示すテーブルである。 実施の形態２においてリクエスタが行うアクセス要求発行手順を示すフローチャートである。 実施の形態２においてトークンマネージャが、各リクエスタに順次ＦＰを付与していくスキームの例を示すフローチャートである。

符号の説明

１０ プロセッサユニット、 １２ トークンマネージャ、 １４ バス、 １６ メモリコントローラ、 １８ メモリ、 ２０ａ 第１入出力装置コントローラ、 ２０ｂ 第２入出力装置コントローラ、 ２２ａ 第１入出力装置、 ２２ｂ 第２入出力装置、 ３０ｎ 第ｎリクエスタ、 ３２ コマンドキュー、 ３４ トークン付与部、 ３６ トークン生成部、 ５０ ＦＰ付与ルールテーブル、 １００ 情報処理装置。

Claims (10)

1. リソースへのアクセス要求の発行許可を求める複数のリクエスタユニットと、
   前記アクセス要求が所定のレートで発行されるように制御したうえで前記リクエスタユニットに発行許可を出す発行レート制御部と、
   発行許可を得た前記アクセス要求を受け付け蓄積し、順次アクセスを実現するアクセス処理部と、
   を備え、
   前記アクセス処理部における前記アクセス要求の蓄積量が所定の第１のしきい値以下であるとき、前記複数のリクエスタユニットの少なくとも一部を、前記発行レート制御部による制御と独立に前記アクセス要求を発行する優先リクエスタユニットとすることを特徴とする情報処理装置。
2. 前記アクセス処理部における前記アクセス要求の蓄積量は、あらかじめ前記第１のしきい値以下の範囲で複数のレベルに区分けされ、前記優先リクエスタユニットの数は、前記レベルによって変化することを特徴とする請求項１に記載の情報処理装置。
3. 前記レベルごとに前記優先リクエスタユニットを指定するテーブルを記憶する記憶部をさらに備え、
   前記発行レート制御部は前記アクセス要求の蓄積量の前記レベルが変化したことを検出した際、前記テーブルを参照して、新たなレベルにおいて前記優先リクエスタユニットとなるべきリクエスタユニットを特定し、その結果を前記複数のリクエスタユニットのそれぞれに対応付けられたフラグに反映させて更新することを特徴とする請求項２に記載の情報処理装置。
4. 各リクエスタユニットは、前記アクセス要求の発行許可を求める前に前記フラグを参照して当該リクエスタユニットが前記優先リクエスタユニットであるか否かを確認し、前記優先リクエスタユニットである場合は、前記アクセス要求の発行許可が得られたものとして前記アクセス処理部に前記アクセス要求を発行することを特徴とする請求項３に記載の情報処理装置。
5. 前記発行レート制御部は、前記リクエスタユニットから前記アクセス要求の発行許可を求められた際、前記フラグを参照して当該リクエスタユニットが前記優先リクエスタユニットであるか否かを確認し、前記優先リクエスタユニットである場合は、前記制御を行わずに発行許可を出すことを特徴とする請求項３に記載の情報処理装置。
6. 前記アクセス処理部における前記アクセス要求の蓄積量が所定の第２のしきい値以下であるとき、
   前記発行レート制御部は、前記優先リクエスタユニット以外のリクエスタユニットによるアクセスで使用するバス帯域の合計が、実装されたバス帯域を越えても前記アクセス要求の発行許可を出すことを特徴とする請求項１から５のいずれかに記載の情報処理装置。
7. コンピュータが、内部のリクエスタユニットによるリソースへのアクセス要求を制御するアクセス制御方法であって、
   前記リクエスタユニットが前記アクセス要求を所定のレートで発行するステップと、
   前記アクセス要求を蓄積し、順次アクセスを実現するステップと、
   を含み、
   前記発行するステップは、前記アクセス要求の蓄積量が所定のしきい値以下であるとき、前記所定のレートで定まるタイミング以外のタイミングでも、前記アクセス要求を発行することを特徴とするアクセス制御方法。
8. 前記発行するステップは、
   発行レート制御部が、前記アクセス要求が所定のレートで発行されるように制御したうえで前記リクエスタユニットに発行許可を出すステップと、
   発行許可を得た前記リクエスタユニットが前記アクセス要求を発行するステップと、を含み、
   前記アクセス要求の蓄積量が所定のしきい値以下であるとき、前記リクエスタユニットの少なくとも一部が、前記発行レート制御部による制御と独立に前記アクセス要求を発行することにより、前記所定のレートで定まるタイミング以外のタイミングでも前記アクセス要求を発行することを特徴とする請求項７に記載のアクセス制御方法。
9. コンピュータが、内部のリクエスタユニットによるリソースへのアクセス要求を制御するアクセス制御方法であって、
   所定のレートでトークンを生成するステップと、
   前記トークンを取得した前記リクエスタユニットが前記アクセス要求を発行するステップと、
   前記アクセス要求を蓄積し、順次アクセスを実現するステップと、
   を含み、
   前記アクセス要求の蓄積量が所定のしきい値以下であるときは、前記トークンを取得していないリクエスタユニットがリソースへのアクセス要求を発行するステップをさらに含むことを特徴とするアクセス制御方法。
10. リクエスタユニットからリソースへのアクセス要求が所定のレートで発行されるように制御したうえで前記アクセス要求に対し発行許可を出す機能と、
    発行許可を得た前記アクセス要求を蓄積する機能と、
    蓄積された前記アクセス要求を順次実現する機能と、
    前記蓄積する機能において蓄積された前記アクセス要求の蓄積量が所定のしきい値以下であるとき、前記リクエスタユニットの少なくとも一部を、前記発行許可を出す機能による制御と独立に前記アクセス要求を発行する優先リクエスタユニットとする機能と、
    をコンピュータに実現させることを特徴とするコンピュータプログラム。

Images